Узнайте нужен ли в Вашей компании Service Desk

8 (495) 726-15-52

Что делать: Сразу внедрять большую систему CRM или двигаться небольшими шагами?

Публикация в журнале "IDO business №3"

Ситуация

Оригинальная бизнес модель компании А дает существенные конкурентные преимущества и вывела ее в лидеры рынка данного вида услуг. Компания А хочет закрепить эти преимущества путем более высокого уровня структурирования процессов. В данный момент компания стоит перед выбором способа организационного развития бизнеса:

  • Быстрое внедрение большой системы, в результате которого появляется возможность структурировать и автоматизировать основные процессы.
  • Планомерное движение к цели.
    • Структурирование и автоматизация процессов (по одному)
    • Когда все основные процессы автоматизированы, возникает возможность внедрения большой системы.

Внедрение большой системы

Обычно внедрение большой системы проходит следующие этапы:

  • Сбор потребностей
  • Сканирование рынка существующих систем
  • Выбор поставщика
  • Демонстрация систем
  • Сравнение систем
  • Описание модели AS-IS
  • Описание модели To-Be
  • Увязка To-Be со стратегией компании и архитектурой системы и Получение готового концепта
  • Написание ТЗ
  • Реализация ТЗ, разработка прототипа
  • Старт прототипа
  • Тестовая эксплуатация прототипа
  • Устранение ошибок и недоработок
  • Сдача системы в промышленную эксплуатацию

Планомерное продвижение к цели

Возможен вариант реструктуризации, состоящий из следующих частей:

  • Определение общей структуры бизнес модели
  • Выделение наиболее критичных «кусков» и определение последовательности реинжиниринга и автоматизации.
  • Реинжиниринг и автоматизация каждого «куска»  состоит из следующих этапов:
    • Описание модели To-Be
    • Увязка To-Be со стратегией компании и архитектурой системы и Получение готового концепта
    • Написание ТЗ
    • Реализация ТЗ, разработка прототипа
    • Старт прототипа
    • Тестовая эксплуатация прототипа
    • Устранение ошибок и недоработок
    • Сдача системы в промышленную эксплуатацию

Ниже мы приводим рассуждения и мысли о плюсах и минусах обоих подходов.

Съест-то он съест, да только кто же ему даст-то?

Предварительный анализ полученной информации говорит о том, что в компании А необходимо довольно специфическое решение по управлению ресурсами предприятия (EnterpriseResourcePlanning (ERP)), использующие стандарты МRP и MRPII.

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

Сроки внедрения подобных систем (ERP) колеблются от 1года в небольших до 3 лет в крупных компаниях. Судя по озвученным срокам внедрения, озвученных поставщиком (36 дней) речь идет именно о внедрении ТИПОВОГО (без учета специфики данного клиента) конкретного решения.

А оно нам надо?

70% внедрений ERP систем заканчиваются провалом (данные Gartner).

Процент неудачных внедрений в России еще выше. С чем связан такой высокий процент неудачных проектов?

Причин, как правило, бывает несколько:

  • Недостаточная зрелость компании
  • Динамика бизнеса (во время внедрения бизнес развивается, а внедренцы настаивают на фиксировании требований в ТЗ), таким образом мы рискуем:
    •  либо заморозить развитие бизнеса (он не будет меняться согласно требованиям времени) на срок внедрения…
    • либо можем просто не внедрить систему, потому что поток постоянных изменений все время увеличивает объем работ для разработчиков и он грозится не закончится никогда. Чаще всего так и происходит.

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

Архитектура и Архитекторы

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

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

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

Выдвигать какие либо претензии к автоматизатору было бесполезно – все заказанное ТЗ было выполнено в полном объеме. А новые потребности возникли уже после закрытий проекта внедрения.

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

К пуговицам претензий нет?

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

Специфика конкретных бизнес процессов

Даже беглый предварительный анализ существующих бизнес процессов компании А показал их достаточную специфичность, если не уникальность. Насколько эта уникальность будет учтена, а не будет предложена замена их «типовыми», предусмотренными в типовом же решении.

Все что угодно, вплоть до слома удачной бизнес модели.

Скорее всего, до этого не дойдет и все застопориться где-то в пути…

Это значит, что бизнес выживет и значит, что самые страшные риски не реализуются. Во всяком случае, мы сильно на это надеемся.

Но…

Остановка процесса внедрения – это блокирование рисков, т.е страховка от еще более страшных последствий.

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

Деньги на ветер

Бывает так, что  мы оплачиваем какие-то работы, которые в дальнейшем ни к чему не приведут.

Почему так происходит?

  • Решение, которое принимали – устарело
  • Поменялась ситуация на рынке
  • Компания оказалась не готова к внедрению.

Могут ли в этой ситуации быть положительные моменты?

Оказывается - могут.

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

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

Во всем, кроме лицензий.

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

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

Привязка к конкретному исполнителю

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

Конкретное решение конкретной компании, как правило, сажает клиента «на иглу» работы именно с этими исполнителями и не позволит в будущем их поменять. Что из этого может следовать:

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

Эволюция, а не революция

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

иметь всегда работающую систему практически на любой момент времени, с полностью документированными:

  • Решениями
  • Процессами

Поэтому очень легко будет:

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

Процесс развития становится менее дискретным и более непрерывным с минимальными рисками.

Скачать статью.