Переход на современные ERP-решения «1С» – дорожная карта, кейсы, рекомендации

Всегда есть какие-то неуспешные проекты. И зачастую с этими неуспешными проектами сами клиенты или франчайзи приходят в фирму «1С» и в качестве арбитражных судей просят разобраться – почему так произошло?

Данный доклад построен на собранной в фирме «1С» информации – почему проект может зайти «в тупик», и как это проявляется.

На основании этого я расскажу, какие 10 составляющих важны для успешного проекта.

1. Цель проекта

При входе в проект необходимо четко понимать, для чего требуется автоматизация – какие у нее цели. Потому что зачастую даже сам заказчик не совсем понимает, для чего ему нужен проект. Он хочет, чтобы было все хорошо, и все. А более конкретно сформулировать не может.

Поэтому при входе в проект необходимо четко знать, что конкретно предприятию требуется – какие у проекта цели.

2. Дорожная карта проекта (приоритеты задач)

Далее эти цели уже разбиваются на задачи, задачи делятся по приоритетам, и таким образом формируется дорожная карта работ.

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

3. Готовность компании идти в проект

Про НСИ. Очень большой процент из проектов, которые «не взлетели», стопорятся как раз на этапе НСИ. Потому что это базис.

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

Зачастую даже сам заказчик не понимает, что происходит с его справочниками, насколько они сложны и важны. А это фундамент, и мы не можем идти в проект, не понимая, на чем будет строиться учет – что у нас стоит на самой земле. Поэтому на НСИ необходимо посмотреть достаточно здраво и честно.

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

Также при определении готовности идти в проект мы должны убедиться в достоверности данных.

Это важно, потому что часто ERP-система приходит на место каких-то лоскутных автоматизаций из зоопарка различных решений – на место этого зоопарка внедряется ERP-система.

И большой процент проблем связан с тем, что в каждой системе разная информация. Допустим, в «Бухгалтерии» – одна сумма на остатках по складам, а в Excel на складе у кладовщика – совершенно другие цифры.

И здесь необходимо понимать, где же правда – какой системе насколько можно верить.

Такие проблемы встречаются довольно часто – к этому необходимо быть готовым.

4. Внедрение от процессов, а не от галочек в программе

Заказчик очень часто думает, что проект касается только ИТ-части. Но мы с вами должны понимать, что автоматизация – это скорее не про ИТ, это скорее про бизнес-процессы. И начинать автоматизацию с кнопок или каких-то галочек – неразумно, потому что процессы – прежде всего.

Как показывает практика и тот анализ, который у нас есть – по-настоящему успешные проекты происходят на стыке с реинжинирингом бизнес-процессов, когда сам проект по автоматизации выступает катализатором для пересмотра бизнес-процессов.

Когда есть какие-то слияния, изменения, приходят новые топ-менеджеры, меняются процессы, и в этом участвует IT-компания – это самые классные по успеху проекты.

Еще одна проблема – функциональные границы и локальность.

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

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

Или еще один пример. Очень часто процесс бюджетирования начинают с планирования – сделали прекрасный план с прекрасными аналитиками, которые можно раскрыть и так, и эдак. А на следующем этапе, когда собирают фактические данные по бюджетированию, оказывается, что факты собрать нельзя – нет источников.

Т.е. любая локальная задача существует в границах большой функциональной задачи – это нужно понимать.

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

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

Да, система стала лучше, мы можем посмотреть какие-то дополнительные разрезы, но у всего есть своя цена – и при внедрении такая система дороже, и при поддержке тоже.

Примерно через год-два вся эта аналитика, которая не нужна функциональному заказчику, постепенно отмирает. И все эти потуги и трудозатраты уходят в никуда.

Везде должен быть баланс – особенно, в НСИ. Не должно быть мало, не должно быть много – должно быть в самый раз.

5. Кадры решают все

Архитектура и кнопки – все это хорошо. Но, как мы все понимаем, кадры решают все.

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

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

В последнее время, как мы знаем, высвобождается большое количество сотрудников, которые работали не на 1С. Для них есть специальные курсы – именно для тех, кто понимает функциональные процессы, но не знает специфику 1С.

6. Рельные полномочия у РП

Важно, чтобы в команде заказчиков был делегирован руководитель проекта.

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

Это должен быть точно приказ на назначение руководителя проекта. И он действительно должен обладать какими-то полномочиями. Это очень важно.

Сама команда, сами функциональные заказчики должны быть готовы к изменениям. Потому что в 1С нельзя реализовать то, к чему они привыкли в Excel, или повторить SAP, или что-то еще.

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

7. Формализация требований – в необходимом и достаточном объеме

Про формализацию требований – здесь также должна быть «золотая середина».

Периодически к нам в фирму «1С» приходят с какими-то нерешенными и плохими проектами – просят разобраться, наказать подрядчика или что-то еще. Такие запросы бывают.

Начинаем разбираться. Поднимаем документацию, чтобы понять, что должно было получиться. А документации особой нет – никакой формализации нет.

Довольно часто клиенты рассказывают: «К нам приходили, показали демо-базу, сказали, что было все хорошо. Было скучно, мы ничего не поняли, но мы поверили, что все будет хорошо. А хорошо не случилось».

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

8. Интеграция с внешними системами

При оценке проекта зачастую забывают о том, что система не находится в вакууме. И недооценивают интеграцию. У нас остается какая-то историческая система.

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

А в настоящее время у нас эпоха интеграций – вокруг множество всяких сервисов.

Со многими сервисам 1С:ERP может интегрироваться «из коробки».

В первую очередь это, конечно же, национальные системы:

• EИC Закупки;

• ГИС ЭПД;

• СБП.

Также 1С:ERP может интегрироваться с другими системами для целей повышения эффективности продаж. Это сервисы:

• Яндекс.Go

• Деловые линии

• Smartway

А также со всеми обязательными информационными системами:

• Честный знак;

• ВетИС;

• ЕГАИС;

• ФНС и т.д.

На слайде – примеры реальных проектов, о которых можно почитать на сайте «1С:Проект года» (проект агрохолдинга «Николаевский» и проект объединённой группы строительных компаний «Сибшахтострой»).

Это примеры – насколько ветвистыми бывают реальные проекты интеграции.

9. Тестовая эксплуатация

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

И когда мы уже начинаем работать непосредственно в системе, самое главное – это не откатиться назад. Мы должны работать именно в системе.

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

Если пользователи начинают возвращаться назад, их уже очень сложно вытащить обратно. У них в прошлой системе была локальная свобода – в Excel можно все, а в ERP-системе у них большие ограничения. Конечно, им это не нравится – мало того, что необходимо себя перестраивать, так еще и меньше свободы.

Но мы же с вами делаем систему не ради какого-то сотрудника. Мы делаем ее ради всей компании. И здесь очень важно не идти назад.

10. Внедряем на года!

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

Должны быть определенные регламенты и договоренности с заказчиком – что же будет дальше, имея в виду, что это очень и очень надолго.

Практика успешных внедрений

Часто задают вопросы, какой примерно срок внедрения.

На слайде – официальные данные, которые собраны на основании отчетов о внедренных решениях. Это информация, сколько месяцев обычно длится внедрение, и какие, в среднем, трудозатраты – просто для ориентира.

Резюме – что нам необходимо для успешного проекта:

1. Определяем цель.

2. Делаем дорожную карту.

3. Определяем готовность команды заказчика идти в проект.

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

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

6. Контролируем, что руководитель проекта – это не просто администратор. Он напоминает о встречах и назначает эти встречи. Он реально должен иметь полномочия и как-то влиять на всю команду со своей стороны.

7. Формализуем требования.

8. Помним, что есть интеграция с внешними системами – особенно обращаем на это внимание, когда оцениваем проект.

9. Закрепляем результаты на этапе тестовой эксплуатации.

10. И внедряем «на года» – необходимо понимать, что будет еще много прекрасных лет с этим заказчиком. Или не очень прекрасных.

На слайде – реальные данные эффекта от автоматизации при переходе на ERP-системы. Эта информация предоставлена непосредственно заказчиками – вы можете подробнее посмотреть показатели эффективности внедрения проектов 1С на сайте «1С:Проект года».

Вопросы

Мы не переходим на ERP. Мы приходим на ERP с нуля. Проект – это производство. Там довольно большой цех и всё сопутствующее: кадры, бухгалтерия и т.д. Но сейчас у нас недобухгалтерия, которая работает «на коленке», и мы пытаемся это все автоматизировать. С чего вы посоветуете начать?

Все зависит от цели. Чего вы хотите?

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

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

Если самое главное для этих целей – это производство, то и начинать нужно с оперативного контура. Вы же не ради бухгалтерского учета и не ради бюджетирования это все делаете. Раз вы внедряете ERP-систему, вы делаете это именно ради производства.

Мы хотели начать именно с бухгалтерии, потому что в бухгалтерии у нас самый большой провал.

Тогда у вас другая цель – вы хотите сократить трудозатраты и сэкономить на сотрудниках.

У нас есть несколько целей. Самая верхнеуровневая глобальная цель связана с анализом и аналитикой. А промежуточные цели – связаны с производством, ремонтом техобслуживания, логистикой и закупками.

Конечно, все очень индивидуально, но верхнеуровнево я бы начала с производства, со складов и закупки.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.