Хроники хаотичного ведения учета и как не стоит внедрять проекты

В этой публикации расскажу об опыте автоматизации одной производственно-торговой компании. Принят я был на работу в качестве программиста 1С для автоматизации оперативно-торгового учета. Начал с изучения текущих систем, сформировал список вопросов, на которые нужно было получить ответы. Стандартная схема: предпроектное обследование, описание текущих бизнес-процессов, составление поэтапного технического задания (черновой вариант). Сбор информации производился произвольно, так сказать "из уст в уста". Никаких документов по стандартам учета, концепции, стратегии не было.

Параллельно у других программистов (нас было 3) шли другие проекты по мобильной системе, документообороту и т.д. Походу проявлялись недочеты текущих систем и по возможности исправлялись. Торговая база была автоматизирована на БП 2. Примерно через месяц так и не получив ответов на 80% вопросов я составил черновой вариант технического задания. Вопросы, по моему мнению, были простыми:

1. учетная политика
2. управленческая структура компании
3. список бизнес-единиц, сфера деятельности, схема обменов данными
4. правила по скидкам, акциям, контроль дебиторки
5. и т.д.

В ходе работы выяснялись все новые и новые подробности в разных участках учета. Главное — не было единого владельца процессов работы. Филиалов около 20, но каждый работал по-своему. У некоторых свои какие-то параллельные торговые базы, к которым они не давали доступ. Также уровень компетенции пользователей оставлял желать лучшего.

Решил я, значит, сделать собрание руководства (до этого было штук 5 наверно) для выяснения как автоматизировать всех в одной базе, если каждый регион работает по своему. Заранее нарисовал схемы бизнес-процессов и отправил всем на почту. Собрались, начали обсуждать.  Решили выстроить одни процессы для всех, но по факту не получилось.
Пытался несколько раз подписать техническое задание у руководства (предчистовой вариант). Не подписали. Как мне сказал директор, IT не хотят отвечать за мои косяки. Т.е. если по каким либо причинам будут косяки, что в любом случае отвечает программист, что, впрочем, подтвердилось. Но об этом позже, идем дальше.

Для начала автоматизации выбрал сперва 3 российских филиала на основе УТ 11. Доработал конфу, доработал шину данных для автоматизации мобильной системы. Развернул тестовую среду, каждому объяснил, как работать, написал инструкции, схемы процессов. Реакция у 2 филиалов почти нулевая. Один филиал тестировал, но вяло. Несколько раз обращался к коммерческому директору, чтобы он, так сказать, "приказал" работать по выстроенной схеме. Исполнительность нулевая. Писал всем и говорил, короче помощи никакой. Проект был наполовину провален. Удалось лишь централизовать базу и перенастроить мобильную систему у одного филиала, остальные забивали документы вручную. Сообщил об этом руководству. Реакция нулевая. Была нулевая, пока не узнали, что не внедрена новая мобильная система (было 2, старая и новая, разработанная в компании). Меня штрафанули на 10% зарплаты. Я начал спрашивать, на каком основании, сказали, что из-за мобильной системы. Начал доказывать, что даже их непосредственный руководитель в лице коммерческого директора не смог повлиять на них, чтобы они протестировали новую систему и т.д. Короче я крайний, доказать не удалось несмотря на все доводы.

В качестве конфигурации для автоматизации филиалов Казахстана была выбрана "Комплексная автоматизация для Казахстана, ред. 2". Тут мне директор говорит, что конфигурация должна быть типовой. ОК. В принципе можно. Хотя в ТЗ, которое так и не подписали, было четко написано, что конфигурация будет доработана.

Назначили из финансового департамента основного ответственного за общение с конечными пользователями. Т.е. сперва показываю, объясняю им, а дальше уже конечным пользователям. Так как филиалов и пользователей немало (14 РП, свыше 100 юзеров), а программистов мало, договорились, что они будут первой линией консультации. Составил поэтапный план внедрения. Времени было мало, оставалось полтора месяца. Нужно было запустить с начала нового года. Месяц был потерян из-за неисполнительности первых 3 РП. Выбрали один РП. Начали тестировать, устранил ошибки. Шел по плану внедрения с чеклистами по областям. Каждый день обновлял статус проекта и отписывал руководству.

Столкнулись с со следующими проблемами:

1. Низкая компетенция пользователей. Мы знали о низком уровне, поэтому разработали инструкции, каждому объясняли, что и как делать. Пришлось объяснять по 3-4 раза, некоторым по 8-10 раз. Было сообщено о проблемных пользователях. Нам ответили, что других не будет в связи с низкой зарплатой, и руководство не будет платить больше.

2. Низкий уровень IT-инфраструктуры. Вообще в компании был режим суперэкономии. Сисадмины уже больше года не могли добиться нового сервера. Нестабильный интернет.

3. Неисполнительность. Как ни парадоксально, руководство головного офиса по факту не могло повлиять на пользователей. Элементарно не читали инструкции, письма. Решили не платить зарплату тем, кто не будет выполнять задачи по проекту внедрения. Вроде зашевелились, кроме одного основного региона. Об этом позже.

4. Неудобность работы в новых условиях. В компании не было понятия резервов товаров. Хотя ей уже больше 10 лет. В инструкциях по полстраницы описывал теорию и практику на максимально простом языке, что такое резерв товаров, разницу между доступным остатком от того, что в наличии и т.д. Контроль минусовых остатков товаров был, но по факту не работал. Некоторые механизмы, которые якобы работали в старой базе, по факту не работали. Операторы подгоняли вручную.

5. Масса ручных корректировок. В ходе проекта была внедрена пакетная работы с документами. Например, 1000 заказов можно было обработать несколькими нажатиями кнопок. Под пакетной обработкой понимается автоматическая создание перемещений, реализаций по каждому складу отдельно. Так вот это все было подробно описано в инструкциях и показано каждому. Но так как в компании много проблем с остатками товаров в старой базе, все привыкли к огромной массе ручных корректировок. Так вот по несколько раз приходилось объяснять, что товар сам резервируется, консолидируется и обрабатывается автоматически пакетами с помощью обработок. Те, кто сразу уловили идею, внимательно перечитали инструкцию и в итоге благодарили, а не уловившие ввиду низкой компетенции (некоторые по- русски толком не могли разговаривать) кровь попили конкретно.

В принципе, масса проблем была решена. Но операторы основного региона не тестировали. Раза 3 говорил своему "связному" (ответственный от финдепа). Связной пригрозил зарплатой еще раз. Реакция, так сказать, не очень. Вообще у этого региона ввиду большого оборота и отсутствия понятия контроля минусового остатка товаров были постоянные серьезные проблемы с инвентаризацией. А для начала тестирования они должны были сделать инвентаризацию. Сделали, ждали результатов инвентаризации в базе неделю.
Возникает серьезная проблема. Примерно за 10 дней запуска связной срочно уезжает.  Говорит, на 2 недели. А как же проект? Обещает быть на связи. ОК. 2 недели потерпим.
В целом картина перспективная 12 филиалов запущены, 1 проблемный, но запущен, 1 на потом на февраль (операторы в отпуске почти весь январь).
До нового года неделя. Решили запускаться. Чеклист велся.Запустились. Запускались поэтапно. Каждые 2 дня по 2 филиала. Действия дублировались и в новой и в старой базе, так как не сезон. Обороты маленькие в силу специфики сферы деятельности.

Первыми запускались 1 основной и 1 маленький филиалы. Первым 1 проблемный и 1 маленький. В силу того, что проблемный нормально не тестировался, им пришлось тяжко. Не читали инструкций. Пришлось работать в 12-часовом режиме. В субботу тоже и в воскресенье по полдня удаленно. Финдеп, который должен был быть первой линией консультации, по факту не исполнял свои обязанности ввиду отсутствия "связного". Как бы он был на связи, но все равно физическое присутствие на рабочем месте в крупнейшем проекте компании это другое.

Вообще, за время работы при мне сменилось несколько компетентных спецов (директора, начальники, менеджера среднего звена). При личных разговорах с ними до увольнения заметил, что они просто вымотаны и после увольнения некоторое время будут просто отдыхать. Так как это еще семейный бизнес, на руководящих должностях 70% были родственники или родственники родственников. Большая часть которых по факту некомпетентны.  

После напряженного режима в течение 2-х месяцев я заболел. Отсутствовал на работе 4 дня. После прихода проблемный филиал до сих пор не мог привыкнуть к контролю минусовых остатков товаров. Реализации, перемещения не проводились. Соответственно страдала отгрузка товаров клиентам. Также была проблема с оверстоками на бортах. Т.е. погружаемый товар просто не вмещался в машину, которая довозила товар клиенту. Алгоритм был таков: если товар есть на борту, то его не надо грузить еще. Также было округление до коробки определенного списка товаров. Я начал проверять код обработки, обнаружил ошибку, исправил.

Короче, сказали, что эта проблема из-за программы. Я признал частично, что в обработке была ошибка, но не критичная. Но тут мне собрали так сказать все мои совершенные "грехи" за проработанный период и штрафанули меня на больше чем ползарплаты. Как и до этого как я ни доказывал, что это не основная причина, уговорить не удалось.

Я начал анализировать, написал отчет по остаткам, реализациям и предоставил доказательства, что не виноват. Бесполезно. Подозревали меня даже в диверсанстве, что я специально это сделал и специально заболел на 4 дня. Но непонятно для чего. В компании в целом отсутствовало понятие оперативности. Например, поступил товар на склад, могли тупо не оформить поступление и дальше продавать, так как контроля минусовых остатков не было. Потом когда обнаруживали, что документ не оформлен в базе, оформляли задним числом. Происходила непонятная котовася или котопес. Короче полная жесть.

Мне предложили отдохнуть, сходить в отпуск и вернуться. Но взвесив за и против, я решил расторгнуть трудовой договор. Причинами стали следующие причины:

1. условия работы. Сварочные, покрасочные, газовые работы производились чуть ли не в 5 метрах от офиса. Никаких норм безопасности. Сидишь такой в кабинете, один день пахнет краской, другой метаном. Зимой холодно, летом жарко. Вы бы видели, какие финты вытворяют карщики. Ютуб отдыхает.

2. невозможность выстроения единой логики работы. Каждый филиал работает по своей какой-то схеме. Финдеп не в курсе, как контролируется дебиторка, рассчитывается себестоимость товара, не знают, что такое учетная политика. И "света в конце туннеля" не было видно.

3. система штрафов. Не доказав до конца, штрафуют даже если ответственные лица за тестирование не выполняли свои обязанности. Т.е. по любому виноват программист. Также не выполнялись даже прямые приказы, подписанные президентом компании.

4. низкая компетенция сотрудников. Из-за концепции строгой экономии денежных средств на заработной плате сотрудников и не только, на работу брали чуть ли не любого. Как следствие от этого страдали все, в том числе и сам новоиспеченный сотрудник. Когда меня штрафанули во второй раз на ползарлаты, при анализе проблемы мною было выявлено, что товар просто залеживался на борту машины и соответственно новая погрузка почти была невозможна, т.е. оборачиваемость товара была низкая. Когда я спросил ответственного за доставку, знаком ли ему термин "оборачиваемость товара" тот ответил: нет.

5. отсутствие фильтра при ведении разработок/доработок. Владельцем всех ИС был финансовый директор. Через него шло согласование доступа, доработки, разработки и т.д. И вот когда какой-то сотрудник предлагает доработать что-то, я отправляю к нему. Он всегда согласовывает. Даже если там нет детализации что и как. За 11 месяцев работы не было ни одного отказа. Тогда вопрос: зачем вообще нужно согласование от финдира?

6. географическая отдаленность. Офис находился там же, где и завод, а заводы находятся в основном на окраинах или вне мегаполисов. Добираться туда не так-то просто.

В итоге для себя я сделал следующие выводы:

1. не идти работать в компании "семейного бизнеса", где на руководящих должностях сидят родственники. Не то чтобы люди плохие, они хорошие, просто некомпетентные.

2. нужно иметь при себе несколько контрольных вопросов в сторону потенциального работодателя при прохождении собеседования. Такие вопросы как: способ оценки запасов, управленческая структура компании, автоматизирован ли процесс доработок/разработок, есть ли согласованный план проектов, имеет ли право разработчик отказать заказчику, описаны ли бизнес-процессы работы, как описаны, по какой методологии и т.д. Скорее всего, список будет расширен. Для чего это надо? Раньше когда я трудоустраивался на другие работы, в основном спрашивал про конфигурации, количество программистов. Но со временем понял, что именно вопросы организационного характера имеют больший вес, нежели чем сама разработка, что от компетенции сотрудников зависит эффективность проделанной работы.

3. не бояться проваливать проекты. После определения ответственных за тестирование, предоставление информации, задач со стороны заказчика регламентно ведите чек лист, контролируйте исполнение. При неисполнении эскалируйте на его руководство и т.д. до самого верха, если надо до первого руководителя. Этот важный момент с первым руководителем, я к сожалению, пропустил. Возможно, если бы он узнал, что реакция со стороны пользователей вялая, подействовал бы на них. Если протестировано мало участков системы (менее 50%), при сильном отставании от графика смело засчитывайте проект проваленным. Сообщите всем. Письмами, звонками, СМС-ками, через Telegram, WhatsUp, Skype и т.д.

4. доверяй, но проверяй. Документируйте все этапы проекта. Не прям все до точки. В проекте должны быть определенные вехи. Подписывайте у руководителей ТЗ, план проекта. Если не подписывают, можете подыскивать другую работу. Не действуйте как в моем случае, если вам не подпишут ТЗ и скажут начать проект, не соглашайтесь. Через полгода, когда руководители спросят у вас, почему не реализован тот или иной механизм, покажете подписанное ТЗ.

5. удостоверяться, что условия работы подходят. Чай, кофе, чистый воздух, климат в кабинете, железо — все это вроде бы мелочи, но начинают напрямую влиять на производительность, если какое-то звено хромает. Работа программиста больше творческая нежели техническая. Еще со школьных времен мне говорили учителя что люди, связанные с умственной работой, тратят больше энергии, нежели связанные с физической.

6. не заниматься неблагодарной работой, не перерабатывать просто так. Все должно компенсироваться и оплачиваться, и надо здесь и сейчас. Никаких потом. Если говорят, мы тебя повысим через 2 месяца, требуйте документ (приказ, предложение о повышении и т.д.). Оговаривайте сразу, что переработки будут оплачиваться в соответствии с трудовым законодательством. Вы, наверное, подумаете, что я страдаю манией величия, но это не так.

7. страхуйте себя. Многие работодатели почти всегда отличные психологи. Психологи не для того, чтобы помочь вам разобраться в себе, а приумножить свой капитал. Часто встречаю случаи, когда работник просто не может уйти по разным обстоятельствам.

Надеюсь, эта информация понадобится кому-нибудь. Ведь не зря же говорят, что надо учиться на чужих ошибках.