1C:Предприятие 8

Задача – привести управленческий учет к стандартам ЕПСБУ, то есть стандартам единого государственного плана счетов.

Перед участием в конкурсе

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

Потенциально возможные варианты реализации:

1. Попытаться реализовать в УПП (на обычных формах!) стандарты ЕПСБУ. Если говорить проще, то взять 1С:Бухгалтерия государственного учреждения 2 (1С:БГУ 2) и попытаться передрать оттуда и адаптировать целевой функционал. Туда же докинуть то, что требуется из 1С:Зарплата и кадры государственного учреждения 3 (1С:ЗКГУ 3) – здесь существенно меньше.

2. Перевести заказчика на ERP 2, заимствуя все необходимое из тех же 1С:БГУ 2 и 1С:ЗКГУ 3.

3. Написать нечто напоминающее интеграционную шину, которая будет обмениваться учетными данными с 1С:БГУ 2 и 1С:ЗКГУ 3. Последние две конфигурации в рамках такой схемы, очевидно, еще нужно внедрить.

4. Дописать производственный блок и все остальное в рамках 1С:БГУ 2 и перевести заказчика на 1С:БГУ 2 и 1С:ЗКГУ 3.

Первые два варианта кажутся наименее рабочими. Почему?

• Стандарты государственного бухгалтерского учета обновляются очень динамично, поэтому вопрос поддержки всех отчетных форм и взаимодействия с многочисленными государственными сервисами становится весьма актуальным. Это касается не только стоимости поддержки для клиента, но и возможности поддерживать актуальность системы в целом.

• Разработка на базе морально и технически устаревшего программного продукта в рамках первого варианта кажется не привлекательной.

• Объем работы представляется наиболее масштабным по сравнению с остальными вариантами. По крайней мере на текущий момент...

• Коммерческие перспективы для нашей компании в рамках доработок и технологических решений, которые будут реализованы, отсутствуют.

Таким образом, остаются варианты 3 и 4. На мой взгляд, наиболее привлекательным является третий вариант. Его единственная, но серьезная уязвимость — большое количество обменов. В рамках этого варианта мы получим набор программных продуктов, непрерывно обменивающихся данными: 1С: УПП — 1С: БГУ 2, 1С: УПП — 1С: ЗКГУ 3, 1С: БГУ 2 — 1С: ЗКГУ 3. Заказчики обычно относятся скептически к таким сложным и тонким обменам.

Четвертый вариант уступает третьему практически всем, за исключением обменов. Здесь он только один – стандартный (ну или почти стандартный в нашем случае) обмен между 1С:БГУ 2 и 1С:ЗКГУ 3.

Наработки, полученные при реализации 3-го и 4-го вариантов, можно тиражировать, так как предприятий подпадающих под подобную реорганизацию достаточно много. А на рынке на текущий момент в этом направлении практически ничего не сделано.

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

К чему это все?

Попробую отражать здесь ход выполнения проекта: как все это будет происходить, какие решения будут приниматься с обеих сторон, какие трудности будут возникать и как они будут решаться (если будут).

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

Что касается тестирования. Я всегда составлял схему кто с кем работает, с чем взаимодействует. Далее составлял скрипт работы и проводил один реальный пример работы со всеми сотрудниками, где "вбивал" в каждого свой скрипт) Более скрипта как перенести результат своей реальной работы в программу им ничего знать не надо.

Очень важно распределить зону ответственности каждого сотрудника, тогда 1 сотрудник будет работать с 1 справочником, 1 документом и 1 отчетом. Или экономист, например, будет работать с 3 отчетами, а технолог только заносить разные вариации спецификаций.

Внедренцы во франчах, конечно, тоже хороши. У них есть просто задача обучить. Но очень важно после обучения уточнить удобно ли работать в программе. Я на своих проектах был волен сам предлагать какие-либо решения автоматизации, результат которых - упрощение работы пользователей.

Поэтому, самое важное когда ты хочешь автоматизировать свой бизнес - это понимать что ты хочешь. А по сути, все что может тебе предложить любая БД - это понимание, что теперь у тебя труднее спиздить материалы) и понимание куда у тебя уходят деньги)

Предисловие

Рассказ руководителя одного из подразделений компании, в которой был запущен проект по внедрению новой управленческой системы. В качестве стека технологий была выбрана платформа 1С, в качестве программного продукта – 1С:ERP 2. История пойдет от первого лица, непосредственно от очевидца и участника событий.

Заказчик

Компания занимается торговлей различными техническими девайсами и комплектующими к ним: закупка товара за рубежом, многоступенчатая система логистики, реализация в России по средствам прямых договоров, а также через государственные закупки, включая гособоронзаказ. Ведется деятельность в рамках "интеркампани". Несколько офисов в России и Китае. Есть свое развивающееся производство.

Что из себя представляла старая информационная система?

Самопал, разработанный давно канувшей в лету IT–компанией, насчитывающей на пике своего могущества не более 10 человек. Система по сути своей визуально представляла одну огромную таблицу в несколько сотен колонок. Работая в программе, вы быстро понимаете, что самая нужная кнопка мыши – это «колесико», потому что будете проматывать экраны вправо, влево, вверх и по диагонали! Плюсы очевидны: после недели работы вы с большой вероятностью накачаете себе правую руку…

Подготовка к проекту

Новый IT–директор (будем звать его Геннадий), находясь две недели в должности, приходит к бескомпромиссному, ну и естественно, самому логичному выводу: нужно внедрять новую систему вчера! На всё про всё потребуется год, бюджет — 120 миллионов рублей, ну и контракт с IT–интегратором, где, уж так сложилось, он является соучредителем! Руководство компании задает резонный вопрос, а как же провести исследование рынка, собрать КП и прочие никому не нужные вещи?.. На что собственники от Геннадия получают ответ, что данные мероприятия для слабаков и неуверенных в себе людей!

Но все же здравый смысл восторжествовал! Пригласили с десяток потенциальных подрядчиков. На общих правах были проведены экспресс–обследования текущего положения дел. Средняя стоимость запуска системы, исходя из всех КП, составила 55 миллионов рублей вместо изначально предложенных Геной 120–ти…

После этого Гена, как настоящий профессионал, стремительно сообщил руководству, что реализовывать проекты дешевле девятизначных цифр – это ниже его достоинства, да и вообще в целом малоинтересное занятие. Далее последовало заявление по собственному, и имя Геннадий было похоронено в анналах истории…

На должность ответственного лица за реализацию проекта со стороны заказчика был назначен технический директор компании. В принципе весьма логичное решение!.. Ибо какая к черту разница: сервера, операционные системы, программы, программирование, настройка принтеров, бизнес–процессы – это же всё совсем рядом!

По идее проект должен был мчаться с разгона в пропасть уже на этом моменте. Однако повезло… Технический директор (будем звать его Алексей) оказался в последствии одним из тех людей, которые позволили реализовать проект хоть в какой–то степени. Стоит отметить, что таких людей было немного…

Подрядчик

Здесь все оказалось весьма прозаично! Выбрали того, кто предложил самую низкую цену. Я бы даже сказал, экстремально низкую по сравнению со всеми остальными соискателями… Но сей факт по загадочным причинам никого не напугал… Возможно подумали, что дескать, если не получится, то хотя бы будет недорого…

Выбор подрядчика за такую низкую стоимость по идее должен был стать вторым камнем преткновения на пути к успешной реализации проекта. Это просто математически небезопасно выбирать одно из экстремальных решений при прочих равных! Но… Повезло и здесь! Ребята оказались весьма достойными и компетентными, пусть и не с самого начала… Но обо всем по порядку…

Технические особенности будущей управленческой системы

• Более 70 уникальных рабочих столов: индивидуальных интерфейсов для различных групп пользователей (в информационной системе работает более 200 пользователей);

• Прослеживание стадий логистики товара в любой момент времени (дополнительные аналитические разрезы, фигурирующие во всех отчетных формах);

• Функционал динамической себестоимости (понимание себестоимости товара в произвольный момент времени без привязки к закрытию месяца);

• Измененная логика формирования себестоимости в рамках специфики бизнес–процессов;

• Интеграция более чем с 80 специализированными онлайн–сервисами;

• Создание многократно используемого (для исключения параллельной работы в двух программах) механизма переноса данных из старой информационной системы в 1С:ERP (размер информационной база–источника — более 1 Тбайт).

Как шел процесс

Выбранный подрядчик клялся и божился, что запустит новую систему за 9 месяцев. Запустили за год… Вот что примечательного происходило на проекте помимо рабочей рутины и производственного ада:

• Месяц 1 — 3

  • 👍 Налаживание отношений между коллективом подрядчика и заказчика.

  • 🤦‍♂ Недостаточное внимание со стороны сотрудников заказчика к процессу внедрения на начальном этапе.

• Месяц 4

  • 👍 Увеличение количества аналитиков и методологов со стороны исполнителя.

  • 🤦‍♂ Полная смена всей команды исполнителя, включая руководителя проекта, через 3 месяца после начала работы. Здесь, кстати, задержка введения системы в эксплуатацию на 3 месяца выглядит весьма ожидаемо. Как раз то на то и выходит.

• Месяц 5

  • 👍 Создание тестовых групп из сотрудников заказчика с сопутствующим премированием и штрафами.

  • 🤦‍♂ Бойкотирование и откровенный саботаж всего мероприятия со стороны сотрудников заказчика.

• Месяц 6

  • 👍 Показательное увольнение особо деятельных и бесстрашных вредителей. И вот это был абсолютно правильный шаг со стороны руководства компании! После этого все поняли, что находятся в одной лодке и стали всячески помогать подрядчику: проявлять активность в чатах, исправно тестировать функционал, оставаться после работы и всячески способствовать.

  • 🤦‍♂ Изменение №1 технического задания с формулировкой «мы не могли всего учесть».

• Месяц 7

  • 👍 Опять налаживание отношений между коллективом подрядчика и заказчика. Руководителям проекта с обеих сторон удалось создать здоровою рабочую атмосферу, превратить два коллектива практически в единую команду.

  • 🤦‍♂ Изменение №2 технического задания с формулировкой «без этого мы никак не сможем работать».

• Месяц 8

  • 🤦‍♂ Решение делегировать специалистам заказчика разработку механизма миграции учетных данных из старой системы в 1С:ERP. Понятие клиент–серверной парадигмы для них являлось чем–то из области теории нано–шлейфов, поэтому несколько миллиардов раз в цикле на клиенте вызывать серверные функции – это вполне ОК, норм… Отладка механизма переноса учетных данных затянулась почти до самого запуска системы.

• Месяц 9

  • 🤦‍♂ Изменение №3 технического задания с формулировкой «за время проекта бизнес–процессы сильно изменились».

• Месяц 10

  • 👍 Не поддаваться давлению со стороны собственников в стиле «все сроки уже прошли, нужно начинать работать в новой программе как есть, отлаживать можно потом, так мы никогда не начнем…»

• Месяц 11

  • 👍 Нахождение специалистов поддержки со стороны исполнителя физически на местах у заказчика.

• Месяц 12

  • 👍 Запуск новой управленческой системы!

Что было дальше?

Казалось бы, плюс–минус happy end! Новая ERP–система введена в эксплуатацию! Нужно выходить на закрытие месяцев, расчет статистических показателей, регламентированную отчетность, увеличение производительности системы и рефакторинг. Про расширение функциональных возможностей, повышение эргономики и прочие хотелки тоже не будем забывать…

Но тут, как гром среди ясного неба, происходит замена руководителя проекта со стороны заказчика (напомню, мы называли его Алексей). Его обязанности ограничивают исключительно техническим отделом, отстраняют от ERP. Как оказалось, в последствии это было начало конца…

Алексей был одной из главных причин успешности внедрения. Человек работал в компании практически с самого ее основания, обладал большим авторитетом, на равных общался с руководителями других отделов, мог на понятном для пользователей языке объяснить и обосновать целесообразность тех или иных решений, принятых в части внедрения управленческой системы.

Новым руководителем ERP–отдела назначают одного из программистов заказчика (назовем его Семён). С какой целью была предпринята такая предельно рискованная рокировка – тайна, покрытая мраком…

Хронология событий после вступления Семёна в должность ИТ–директора

• Приостановка работы с подрядчиком на 1,5 месяца, инициированная Семёном;

• Перевод взаимодействия с подрядчиком с абонентского варианта на почасовой учет работ (потрясающее решение в рамках проекта такого масштаба);

• Стоимость услуг подрядчика увеличивается в 2,5 раза в рамках почасовой тарификации;

• Подсчет и обсуждение часов за выполненные подрядчиком работы занимает большую часть времени у Семёна и руководителя проекта со стороны подрядчика;

• Попытки стремительного увеличения собственного IT–отдела компании (причем рекрутировались только программисты… аналитик, я так понял, это вообще ненужная позиция);

• Попытки увести специалистов у подрядчика;

• Разрыв отношений с подрядчиком;

• Предельное ухудшение отношений с руководителями отделов и прочими сотрудниками собственной компании;

• Обрушение линии поддержки программного продукта, ибо собственными силами не справлялись;

• Набор в отдел сопровождения ERP порядка 20 человек, практически не взаимодействующих друг с другом (очень разделяй и очень властвуй);

• Понимание, что самостоятельно выйти на получение в управленческой системе финансового результата и прочих сопутствующих показателей не получится;

• Отсутствие полной управленческой картины у финансово–экономического отдела, отдела закупок, отдела продаж и отдела по логистике;

• Невозможность выплаты переменной составляющей заработной платы (процентов) менеджерам ввиду крайне скудной информации о финансовых показателях (проценты платятся с прибыли всем: продажникам, закупщикам, логистам, таможенным брокерам);

• Уход в полном составе одного из отделов продаж;

• Безуспешные (вот уже два месяца) поиски нового подрядчика (никто из 1С–франчайзи и прочих интеграторов не хочет во все это вписываться)…

Что в итоге

Система деградирует семимильными шагами — это положение дел на текущий момент.

Результат трудов такого большого количества людей приведен в негодность одним человек — это, если смотреть поверхностно. На самом деле виноваты если не все, то очень многие: от собственников бизнеса до сотрудников подрядчика.

Причин такого мегапрофака можно перечислить великое множество! Я же в свою очередь остановлюсь на тех которые мне озвучил очевидец событий и добавлю немного через призму своего опыта:

• Ошибочное решение собственников бизнеса: если система введена в эксплуатацию, то "скрипач теперь не нужен, дядя Вова";

• Невозможность специалистов подрядчика донести до руководства компании фатальные последствия расставания на текущем этапе (с заказчиком нужно работать не только в рамках программного продукта, но и за столом переговоров, причем регулярно);

• Кадровые ошибки заказчика при формировании собственного IT–отдела: как минимум начинать нужно было с грамотного IT–рекрутера, который бы профессионально выстроил систему подбора IT–специалистов;

• "Программисты на фиксе — это не внедренцы" — действительно истина во языцех. Внедренцы — это специалисты с железобетонными нервами и стальными первичными мужскими половыми признаками (как мужчины, так и женщины), люди которые умеют не только писать программный код, но и качественно на понятном языке взаимодействуют с пользователями, могут отстоять необходимость идти на жертвы в эргономике решения в угоду его устойчивости, объяснить клиенту перспективы и последствия того или иного предпринятого шага, не психовать и не злиться на пользователей в конце концов, получая львиную долю негатива в свой адрес;

• Отсутствие понимания со стороны руководства, что хороший программист или аналитик не равно хороший руководитель. Чтобы руководить нужно не ненавидеть людей и уметь брать на себя ответственность! Семён этим критериям не соответствовал от слова совсем. Алексей и руководитель проекта со стороны подрядчика соответствовали полностью.

• Ошибка Семёна — он родился (со слов автора).

Если отозвалось, то можно подписаться...