Если отбросить вопросы бюджета, сроков и технических ошибок, у неудачных внедрений часто есть две основные причины:
- Первая – новая система в итоге не совпадает с тем, как работает или должен работать бизнес.
- Вторая – сотрудники не принимают изменения и не хотят работать по-новому.
Обе проблемы только на первый взгляд относятся к самой информационной системе. На деле значительная часть работы с ними находится за пределами 1С и относится именно к управленческому консалтингу.
Проблема №1. Система не совпадает с бизнесом
В самом упрощённом виде есть два подхода к автоматизации.
Первый: компания готова менять свои процессы под логику новой системы.
Второй: информационную систему планируют настроить под процессы, которые уже сложились в компании.
На практике почти любой проект находится где-то между этими двумя крайностями. Часть процессов имеет смысл изменить, часть – сохранить и учесть при настройке системы. Но проблемы возникают в обоих случаях.
Вариант 1. Бизнес должен был измениться под новую систему – но не изменился
Предположим, на старте проекта была договорённость о том, что вместе с автоматизацией компания перестроит часть процессов.
Например, разные отделы продаж должны начать работать по единой технологии, вести сделку с одинаковыми этапами. Нужно перераспределить зоны ответственности, назначить владельцев процессов, изменить порядок согласования документов, нанять дополнительных сотрудников или по-другому организовать рабочие места. Систему проектируют уже под эту будущую модель.
Проходит несколько месяцев, решение готово к запуску – а внутри бизнеса ничего не поменялось. Отделы продолжают работать каждый по-своему, новые сотрудники не наняты, ответственность не перераспределена, согласованные правила существуют только в документах.
В результате система может быть настроена правильно. Только настроена она под бизнес, которого пока не существует.
Это достаточно распространённая проблема организационных изменений. У руководителей и сотрудников есть текущая работа, клиенты, продажи, производство, срочные задачи. Изменения, которые договорились реализовать в рамках проекта автоматизации, постепенно уходят на второй план.
Поэтому одной договорённости о том, что «к запуску мы всё поменяем», обычно недостаточно – нужен бизнес-трекинг.
Если в проекте запланированы изменения на стороне компании, кто-то должен следить за тем, чтобы они действительно происходили. Эту функцию бизнес-трекер и выполняет. После обследования у него есть перечень организационных изменений, которые заказчик взялся реализовать к определённым этапам проекта.
Трекер регулярно встречается с ответственными и проверяет:
- что уже реализовано;
- что должно было быть сделано, но «не случилось»;
- почему возникла задержка;
- что требуется сделать на следующей итерации;
- сохраняются ли исходные бизнес-цели проекта.
Если договорились, что два подразделения будут работать по единому процессу, недостаточно просто зафиксировать это решение. К моменту запуска системы процесс действительно должен стать единым. Если решили создать новую роль или изменить ответственность сотрудника, это тоже должно произойти не после запуска, а заранее.
Бизнес-трекинг помогает компании не потерять фокус на изменениях среди текущей операционной работы. Можно сказать, что трекер становится внешней «силой воли» проекта: не принимает решения вместо руководства, но помогает довести уже принятые решения до реализации.
Тогда к моменту запуска система и бизнес встречаются в одной точке: процессы, под которые проектировалась система, действительно существуют в компании в том виде, в котором необходимы, чтобы автоматизация работала.
Вариант 2. Систему собирались настроить под бизнес – но сам бизнес изучили недостаточно
Вторая крайность выглядит иначе. Компания не собирается серьёзно менять свои процессы. Задача интегратора – понять, как всё устроено сейчас, и настроить систему соответствующим образом, доработать там, где необходимо, типовой функционал.
На первый взгляд это проще. Но здесь появляется другой риск: процессы нужно знать действительно хорошо. Недостаточно просто спросить, какие документы нужны пользователям, какие отчёты они хотят видеть и какие функции должны быть в 1С.
Нужно понимать, как в реальности проходит работа. Как появляется заказ? Кто и в какой момент принимает решение? Как информация переходит из продаж в производство? Кто согласовывает закупку? Что происходит, если стандартный сценарий нарушается? Где сотрудники используют официальные правила, а где работают по исторически сложившимся договорённостям?
Часто даже сам собственник знает эту картину только на верхнем уровне – и это нормально. Задача собственника или генерального директора не состоит в том, чтобы помнить каждый шаг каждого процесса.
Основная часть знаний распределена между руководителями подразделений и ключевыми сотрудниками. Более того, один и тот же процесс в двух отделах может проходить по-разному, хотя формально компания считает его единым.
Поэтому перед проектированием системы нужно обследовать не только будущую 1С, но и сам бизнес.
Консалтинговое обследование – это не список настроек 1С
В проектах автоматизации словом «обследование» могут называть очень разную работу.
Например, под обследованием может подразумеваться, что аналитики выясняют, какие справочники, документы, роли и отчёты понадобятся в системе. Это технически необходимо, но для понимания бизнеса недостаточно.
Консалтинговое обследование начинается с другого вопроса: зачем компания вообще затеяла проект и что в результате должно измениться в бизнесе?
Поэтому работа начинается с собственника, генерального директора или других руководителей, которые отвечают за результат. Вместе с ними фиксируются бизнес-цели проекта.
Например:
- своевременно получать управленческую отчётность;
- уменьшить операционную нагрузку на руководство;
- повысить управляемость;
- ускорить выполнение заказов;
- снизить количество ошибок в процессах;
- подготовить бизнес к масштабированию.
После этого проходят интервью с руководителями подразделений и ключевыми сотрудниками. Команда разбирает процессы «на местах», связи между отделами, роли, зоны ответственности и существующие проблемы.
В результате появляется схема того, как компания действительно работает сегодня, а не того, как, по мнению руководства, она должна работать.
Уже на этом этапе часто обнаруживаются вещи, которые можно улучшить независимо от автоматизации: лишние согласования, дублирование функций, размытые зоны ответственности, разрывы при передаче информации между подразделениями.
Не все существующие процессы стоит переносить в новую систему
Хорошее обследование нужно ещё и потому, что автоматизировать существующий процесс «как есть» – не всегда правильное решение.
Если процесс неудобный, избыточный или просто исторически сложился неудачно – его перенос в информационную систему не исправит проблемы. Компания получит тот же процесс, только теперь он будет автоматизирован.
Поэтому после описания текущей ситуации нужно определить, что имеет смысл сохранить, а что изменить.
Формируется перечень проблемных зон и изменений: где есть дублирование, где не определена ответственность, какие операции занимают лишнее время, какие процессы отличаются между подразделениями и должны быть унифицированы.
Затем команда определяет приоритеты. Не всё нужно перестраивать одновременно. Есть изменения, без которых проект не достигнет своих целей, а есть улучшения, которые можно перенести на этап будущего развития. Так появляется целевая модель процессов, под которую уже можно проектировать систему.
Обычно нужны оба подхода одновременно
В реальном проекте редко встречается чистый сценарий: либо бизнес полностью меняется под систему, либо система полностью повторяет существующий бизнес. Чаще происходит и то и другое.
Какие-то процессы разумнее изменить. Например, унифицировать работу нескольких подразделений или убрать лишнее согласование.
Какие-то процессы принципиально важны для бизнеса, например, помогают создавать преимущество над конкурентами, поэтому уже информационная система должна учитывать их специфику.
Получается единая цепочка:
- Понять бизнес-цели проекта.
- Разобраться, как компания работает сейчас.
- Определить, какие процессы сохраняем, а какие меняем.
- Спроектировать систему под будущую модель.
- Помочь бизнесу реализовать запланированные изменения.
- Запустить систему тогда, когда и технологическая, и организационная части готовы друг к другу.
Поэтому обследование и бизнес-трекинг – не две отдельные дополнительные услуги. Это части одной задачи: сделать так, чтобы к моменту запуска автоматизированные процессы совпадали с фактической работой компании.
Проблема №2. Люди не хотят работать в новой системе
Даже хорошо спроектированная система может не дать результата, если команда её не принимает.
Причины сопротивления бывают разными. Сотрудники привыкли работать по-старому. Боятся, что новые правила усложнят их работу. Не понимают, зачем вообще затеяли проект. Опасаются усиления контроля. Считают, что новая система создана людьми, которые не понимают их реальных задач.
Особенно легко получить такую реакцию, если пользователей подключают только в самом конце: «Вот новая система. С понедельника работаем в ней».
Компания формально провела внедрение. Фактически сотрудники воспринимают его как навязанное сверху изменение, в создании которого они не участвовали. Отсюда появляются знакомые формулировки: «нам так неудобно», «раньше было быстрее», «нас никто не спросил».
В худшем случае система начинает использоваться частично, сотрудники ищут обходные сценарии или продолжают параллельно вести старые таблицы и документы.
Пользователей нужно вовлекать до запуска
Работу с сопротивлением поздно начинать на этапе обучения, за неделю до старта эксплуатации. Людей нужно вовлекать уже на этапе обследования и проектирования.
Это не означает, что каждый сотрудник должен принимать архитектурные решения или определять стратегию автоматизации. Но человек должен иметь возможность объяснить, как он работает, рассказать о существующих проблемах и ограничениях, высказать мнение о будущем процессе.
Для этого используются интервью, встречи рабочих групп, фасилитация. При обсуждении процессов важно не только собирать требования, но и организовать работу таким образом, чтобы участники действительно слышали друг друга, договаривались и участвовали в выработке решения.
Тогда сотрудники постепенно становятся не «жертвами автоматизации», которым принесли чужую систему, а соавторами изменений. Они понимают, почему меняется процесс, какие проблемы решает новая модель и откуда взялись решения, реализованные в системе.
Это не исключает сопротивление полностью, но значительно снижает его.
Можно ли провести автоматизацию без консалтинга
Теоретически – да.
Если в компании уже выстроена система управления, процессы описаны и одинаково выполняются разными подразделениями, зоны ответственности определены, руководство умеет самостоятельно проводить организационные изменения, а внутренняя команда способна удерживать их в фокусе – отдельный консалтинговый блок может быть значительно меньше.
Но чем дальше бизнес от такой картины, тем выше риски проекта без консалтинга. Если процессы не описаны, в разных подразделениях работают по-разному, зоны ответственности размыты, изменения регулярно откладываются, а пользователи узнают о новой системе незадолго до запуска – автоматизация эти проблемы не устранит.
Скорее наоборот – информационная система сделает существующие противоречия заметнее. В итоге может оказаться, что:
- система настроена под процессы, которых в компании нет;
- существующие неэффективные процессы просто перенесли в 1С;
- потребовалось значительно больше доработок, чем планировалось;
- сотрудники не приняли новую модель работы;
- сроки и бюджет выросли;
- часть пользователей работает по-старому;
- руководство компании получило новую систему, но не получило ожидаемого бизнес-результата.
Консалтинг не является гарантией успешного проекта. Но он позволяет заранее разобраться с одной из самых сложных частей автоматизации – самим бизнесом и людьми, которые в нём работают.
Если вы планируете автоматизацию и хотите понять, какие изменения потребуются не только в 1С, но и в самом бизнесе, можно начать с обследования. Оно поможет увидеть текущие процессы, определить проблемные зоны и понять, каким должен быть проект, чтобы новая система решала реальные задачи компании.
Хотите получить пример обследования или оценку стоимости? Оставьте заявку по кнопке ниже.
