proerp

Крупные игроки российской IT-отрасли, входящие в АПКИТ (Ассоциацию предприятий компьютерных и информационных технологий), высказались против создания консорциума для разработки государственной ERP-платформы. Об этом свидетельствует протокол заседания правления, где присутствовали Филипп Генс («Ланит»), Борис Нуралиев (1С), Илья Сивцев («Астра») и другие.

Позиция рынка: Лидеры отрасли считают, что тратить бюджетные средства на новую систему неразумно, поскольку в России уже есть готовые ERP-решения.

Конфликт с госполитикой: Проект также противоречит схеме «рынок в обмен на инвестиции», запущенной в 2023 году. Согласно ей, компании вкладывают миллиарды в развитие своих продуктов, получая льготы при госзакупках.

Фактически это официальная позиция ведущих разработчиков ERP-решений, закрепленная документально, но не на словах.

Ситуация выглядит предсказуемой: речь идет о централизации вокруг одного из самых прибыльных сегментов IT. Примечательно, что аналогичные процессы в других сферах — госучете, медицинских информационных системах — ранее проходили без возражений. Тогда сотни интеграторов лишились работы, а рынок перешел под контроль крупных вендоров… тех самых, что сейчас заседают в правлении АПКИТ!

Источник: ERP: Решения для бизнеса

Проект масштабной ERP-системы инициирован председателем Правительства РФ Михаилом Мишустиным. Минцифры поручено сформировать консорциум для реализации этой задачи. Участникам группы предстоит выявить стоп-факторы перехода бизнеса на российские решения и предложить способы их устранения. Ожидается, что государство окажет поддержку в реализации проекта.

Мнение

1. Необходимость импортозамещения
   Создание отечественной ERP-системы – логичный шаг в условиях санкций и ухода западных IT-решений. Такие системы, как SAP и Oracle, долгое время доминировали в корпоративном секторе, и их замещение – вопрос не только технологический, но и стратегический. Если Россия сможет предложить конкурентоспособный продукт, это снизит зависимость от иностранного ПО и укрепит цифровой суверенитет.

2. Стоимость и сроки: адекватны ли?
   $1 млрд за 10 лет – сумма значительная, но не запредельная для разработки ERP-масштаба. Для сравнения, SAP ежегодно инвестирует сотни миллионов в развитие своих продуктов. Вопрос в эффективности расходов: будет ли проект прозрачным, или часть бюджета «растворится» в бесконечных пилотных версиях и доработках? Важно избежать сценария, при котором через 10 лет получим устаревшую систему, неспособную конкурировать даже с открытыми аналогами.

3. Кто войдет в консорциум и каковы риски?
   Если в разработку включатся крупные игроки (например, "1С", "Русал", "Северсталь"), это повысит шансы на успех. Однако есть опасность, что проект превратится в бюрократическую имитацию с бесконечными согласованиями. Кроме того, ERP – это не только код, но и экосистема: интеграции, поддержка, обучение. Если бизнесу будет невыгодно переходить на новую систему, даже господдержка не спасет.

4. Технологический суверенитет vs. глобальная конкуренция
   Российская ERP должна быть не просто заменой SAP, но и современным продуктом с поддержкой AI, блокчейна (если это актуально) и облачных технологий. Иначе бизнес, особенно работающий на экспорт, просто не примет её. Кроме того, важно обеспечить совместимость с международными стандартами – иначе компании окажутся в цифровой изоляции.

Перспективы

Инициатива Мишустина – правильный шаг, но сложный. Успех зависит от трех факторов:

• Реальные потребности бизнеса (а не просто желание чиновников отчитаться).

• Технологическая гибкость (чтобы система не устарела ещё до релиза).

• Экономическая целесообразность (чтобы компании добровольно переходили на новое ПО, а не под административным давлением).

Если проект реализуют грамотно, это может стать прорывом для российской IT-индустрии. Если нет – ещё одной дорогой, но бесполезной "импортозаместительной" инициативой.

Источники

interfax, ERP: Решения для бизнеса

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

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

Обнаружив данную закупку на электронной площадке, мы начали прикидывать целесообразность участия, а также потенциальную стратегию, с помощью которой можно все это реализовать в установленный срок (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С: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–специалистов;

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

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

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

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