Ранее мы уже разбирали ключевые причины провала проектов по автоматизации учета. Пришло время для второй части: ещё 5 факторов, которые могут привести внедрение к краху. Изучите, чтобы не повторить ошибок.
1. Неверно выбрали систему
Представьте, что купили мощный спорткар, а ездить на нём негде: разве что на работу в нескольких остановках от дома. Да и будем честны: даже на работу проще на метро, потому что пробки. В итоге миллионы пылятся в гараже.
То же бывает и с 1С. Разница между более и менее высокоуровневыми продуктами фирмы достигает сотен тысяч рублей. Можно сэкономить и упустить возможности для развития бизнеса. Или наоборот — вложиться и не использовать и половины функционала.
Некая торговая компания нуждается в автоматизации. У руководителя на слуху примеры успешных внедрений «1С:ERP». Хотя «1С:ERP» в основном применяют на производственных предприятиях, может сложиться впечатление, что система хорошо заработает и здесь. Не исключено, что это так. По данным консалтингового агентства Panorama Consulting Group, 8% всех внедрений ERP приходятся на ритейл, а 10,2% — на оптовую торговлю. ERP помогает торговым компаниям управлять логистикой, поставками, движением товаров, вести учёт и планирование финансов и т.д.
Но потом оказывается, что стоимость внедрения «съест» ощутимую часть годового оборота клиента (свыше 1%). Это повлечёт за собой стремление сэкономить, а оно — дополнительные риски. Стоит ли игра свеч? Особенно, если решить первоочередные задачи можно с помощью более простых продуктов, их комбинации и доработки.
Другая ситуация: клиент переходит на «1С:ERP» с «1С:УПП». Фирма «1С» прекратила поддержку «1С:УПП», и теперь доработки, связанные с необходимостью сдавать регламентированную отчётность, обходятся дорого. Но заменять систему лишь потому, что предыдущая устарела, — невыгодная стратегия. Лучше превратить неизбежные расходы в инвестиции.
Для этого нужно провести реинжиниринг бизнес-процессов. Выделить проблемные места, упорядочить их и соотнести с типовыми процесса- ми в будущей системе, чтобы найти способы перевода в оптимальный вид. Также важно выяснить, с какими задачами плохо справлялась старая программа и почему. Неверно думать, будто миграция на «1С:ERP» (или любое другое ПО) мгновенно решит накопившиеся проблемы. Если не сделать «работу над ошибками», они никуда не денутся — просто проявятся на более высоком технологическом уровне.
2. Методология не подходит проекту
Некоторые клиенты настаивают, чтобы внедрение велось по классической каскадной методологии. Она кажется более надёжной: подробное описание всех этапов на старте, фиксированный бюджет и т.д. Однако чем сложнее продукт, тем дольше длится проект: скажем, «1С:ERP» внедряют до трёх лет. За это время бизнес-процессы нередко меняются до неузнаваемости. Спустя пару месяцев аналитики могут моделировать то, чего уже не существует.
Проект вообще может развернуться на 180 градусов. Это произошло с одним из наших клиентов — крупным пищевым производством. Компания переходила с SAP на «1С:ERP», но в процессе у неё появился новый собственник со своей системой. Потребность во внедрении «1С:ERP» отпала, возникли совсем другие задачи.
Гибкие методологии более адаптированы к таким ситуациям. Вот почему мы нередко советуем работать по Agile. В этом подходе сохранены все ключевые этапы (сбор требований, обследование, моделирование, разработка, настройка, введение в опытно-промышленную эксплуатацию), но функциональные блоки внедряются последовательно. Если клиенту в первую очередь нужно казначейство, сначала запускают его, потом повторяют цикл для других блоков. Это позволяет выявлять недочёты прямо по ходу проекта и быстро перестраиваться в случае необходимости.
3. Чрезмерно сжатые сроки
Компания по производству электрооборудования обращается с запросом перейти с SAP на«1С:ERP»за месяц. В представлении заказчика это просто: достаточно взять и перенести остатки и историю данных.
Так ли это на самом деле? Нет. Уже после инициации проекта внедрение должно включать в себя следующие этапы.
1. Обследование
Зачем? Выяснить структуру компании, какие бизнес-процессы и функции выполняются, что реально необходимо переносить.
Что даёт? Оцифрованная картина бизнес-процессов.
2. Моделирование
Зачем? Показать, как бизнес-процессы будут выглядеть в новой программе, выявить функциональные разрывы.
Что даёт? «Ваш» процесс на новом ПО.
3. Формирование ТЗ и разработка
Зачем? Доработать ПО, разработать инструменты переноса остатков и данных.
Что даёт? ПО сделано под вас.
4. Подготовка к запуску и запуск
Зачем? Подготовить пользователей к работе с программой, протестировать функциональность, перенести остатки и данные, ввести систему в эксплуатацию.
Что даёт? Обученные сотрудники = спокойные сотрудники. Сопровождение «за руку».
За короткое время (около 3 месяцев) можно развернуть MVP — минимально жизнеспособный продукт, т.е. первую рабочую версию системы, способную закрывать критические задачи. Однако в дальнейшем, если компания хочет задействовать функциональность на полную мощность, потребуется донастройка и доработка программы.
4. Не предоставили исполнителю всю информацию
На начальных этапах исполнитель активно интервьюирует инициаторов проекта и пользователей, задаёт вопросы о бизнес-процессах, ездит на производство, чтобы увидеть всё своими глазами. Эти встречи определяют работу на месяцы вперёд, поэтому на них важно добиться полной прозрачности. Не всегда это удаётся с первого раза. Заказчик может считать, что те или иные детали очевидны или второстепенны.
Например, с одним из наших клиентов мы недостаточно подробно проговорили, как у него организован заказ сырья. Уже на демонстрации смоделированных планов производства и закупок выяснилось, что он заказывает сырьё не на один следующий месяц, а на два-три, и планирует объём не на основании конкретных цифр, а «по наитию». В результате часть работы мы проделали впустую.
Иногда руководство умышленно замалчивает проблемы или «серый» учёт. Иногда информацию скрывают сотрудники, которые бояться стать легко заменяемыми.
Известен случай, когда менеджер не рассказывал, как формируется план закупок комплектующих исходя из потребностей предприятия. Из-за этого исполнитель не мог проектировать блок управления снабжением.
Любая недосказанность рано или поздно всплывает на поверхность и вредит процессу. Работу приходится переделывать, бюджет — увеличивать. Поэтому мы призываем клиентов делиться всей информацией, которая может иметь отношение к делу.
5. Слишком много доработок
Молодые гибкие компании, которые только приступили к автоматизации, без проблем подстраиваются под логику учётной системы. Если же у клиента уже сформировалась сложная структура бизнес-процессов, в типовую конфигурацию она скорее всего не уляжется. Чтобы не перекраивать все процессы, в том числе вполне эффективные, систему дорабатывают.
Здесь нужна осторожность. Некоторые исполнители чересчур увлекаются доработками, а изменения «родного» кода могут привести к сбоям. Кроме того, работоспособность системы может нарушиться при обновлении. Это критично для программ, в которых формируется отчётность для сдачи в контролирующие органы: они обновляются особенно часто. Между тем грамотная настройка типового функционала справляется даже с нестандартными запросами пользователей.
Однажды к нам обратилась сотрудница заказчика, для которого мы осуществляли сопровождение «1С:ERP». Она спрашивала, нельзя ли вывести кнопку «Связанные документы» в шапку документа «Заказ клиента». В «Заказах» она проверяла информацию в табличной части и попутно отслеживала, есть ли связанный документ «Реализация товаров и услуг». Для этого приходилось постоянно кликать на «Ещё», переключаться между окнами, потом возвращаться. За несколько минут мы вывели нужную кнопку в шапку и помогли сотруднице сэкономить пару часов в неделю.
Если вам предлагают доработать систему, уточните, действительно ли ваши задачи не решаются через администрирование интерфейса и настройку прав пользователей. На этот вопрос ответят аналитики: именно их стоит привлекать к проекту в первую очередь. Аналитики проведут качественное обследование, поймут, какая конфигурация подходит клиенту, как её настроить, какие данные перенести и пр. Хороший аналитик сможет описать требования к доработкам и поставить задачу программисту, а хороший программист выполнит её с минимальным вмешательством в типовую архитектуру.
Начать дискуссию