В шапке
Стратегии автоматизации бизнеса

Стратегии автоматизации бизнеса

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

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

То есть у компании, решившейся на автоматизацию процессов или систем управления, есть всего 3 стратегии автоматизации:

  • Автоматизация на базе коробочного программного продукта;
  • Доработка коробочного продукта под требования компании и его внедрение;
  • Разработка программного продукта под свои требования «с нуля» и последующее внедрение.

Для того чтобы выбрать стратегию автоматизации, нужно проделать ряд действий:

  • Описать автоматизируемые процессы или систему управления,
  • Определить проблемы в описанных процессах и найти для них решения,
  • Разработать требования к системе автоматизации,
  • Изучить существующие коробочные программные продукты на предмет того, какой % требований реализован в них.

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

В таком случае алгоритм выбора стратегии автоматизации может быть следующий:

Компания, решившаяся на автоматизацию бизнеса на базе коробочного решения, должна понимать, что ей придется перестроить свои процессы под те алгоритмы, которые в это решение «зашиты». Обычно такие алгоритмы основаны на так называемых «лучших практиках». Однако не всякой компании они подойдут. Я знаю несколько примеров, когда руководители компаний покупали коробочное решение, не изучив заложенные в него лучшие практики, а затем не смогли (или не захотели) изменить процессы своего бизнеса. И в итоге деньги на программное обеспечение были потрачены напрасно.

Доработка коробочного решения под свои требования выглядит наиболее привлекательно для большинства руководителей компаний. Но и эта стратегия несет в себе много рисков. В частности, глобальные доработки программного продукта, как правило, приводят к дополнительным непредвиденным при планировании объемам работ (а значит, к превышению планового бюджета и сроков). Кроме того, обновлять доработанный коробочный программный продукт становится непросто, и вдобавок нужно выстраивать процессы поддержки пользователей (так как разработчик «коробки» оказывает услуги по поддержке пользователей только в части того функционала, который в ней есть).

Третий вариант – разработка под заказ – в наше время выглядит практически фантастикой. Несколько раз про такие проекты я слышал следующие высказывания: «Зачем изобретать велосипед? Неужели под ваш вид деятельности еще не написано коробочное решение?». Как я недавно узнал, в некоторых видах деятельности в Беларуси (например, в оказании страховых услуг) существует один-единственный коробочный продукт и одна компания, которая его развивает. Риски при внедрении такого коробочного решения велики – если компания-разработчик закроет свой бизнес, поддерживать и развивать программный продукт в случае отсутствия описания его архитектуры будет крайне сложно. Вот и задумываются в такой ситуации о разработке под заказ. Об этой стратегии также размышляют в случае, когда существующий коробочный продукт не закрывает и 50-80% требований к нему (на диаграмме написано 80%, но цифра эта условная и выведена не на основании каких-то экспериментов или статистики). При выборе этого варианта стратегии автоматизации сразу нужно решать вопросы поддержки пользователей и развития продукта. Кто это будет делать и на каких условиях? Часто при выборе этой стратегии компания создает собственное подразделение автоматизации бизнеса, которое и занимается поддержкой и развитием продукта.

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

Но если вы хотите выбрать стратегию автоматизации на основании более точных расчетов, то после анализа рисков нужно сделать прогноз TCO (англ. Total Cost of Ownership) для всех трех вариантов стратегии, и после этого выбрать вариант с наименьшим значением TCO. Я понимаю, что такой анализ займет много времени и обойдется дорого, поэтому в большинстве случаев решение о выборе стратегии будет приниматься сразу после проработки списка рисков по каждой стратегии. Но лучше уж так, чем просто на основании интуиции.

В следующей статье я планирую подробнее описать ход подготовки бизнес-процессов к автоматизации.

P.S. После публикации данной статьи я получил комментарий от коллеги, обсуждение которого навело меня на идею о четвертой стратегии автоматизации бизнеса, которая основана не на изучении бизнес-процессов через их описание. Эта стратегия подразумевает сбор и анализ требований к системе автоматизации путем использования прототипов будущего программного продукта. В качестве прототипов можно взять уже имеющийся под руками программный продут, чтобы через работу с ним отладить процессы и уточнить требования к будущему программному продукту. Как пример: для управления одним из проектов по разработке программного продукта мы использовали scrum. для автоматизации процессов scrum достаточно было бумаги и доски, но команде хотелось работать в каком-нибудь программном продукте. И мы нашли бесплатный облачный сервис, в котором начали работать с артефактами нашего проекта, постепенно внедряя процессы scrum. После длительного использования бесплатного продукта мы написали список пожеланий, которых нам не хватало, и разработали собственный программный продукт, который достаточно быстро внедрили для своей команды. Надо отметить,что иногда для прототипа можно обойтись MS Excel. однако отмечу, что данная стратегия лично мной была апробирована для автоматизации процессов разработки и внедрения программных продуктов для небольшой команды. как работает эта стратегия для других задач по автоматизации процессов - я пока не знаю.

Комментарии (0)
Войти как