Как определить готовность процесса к автоматизации

“Пришли неподготовленные? Сейчас мы вас разденем!” — Сергей Мироненко о готовности бизнеса к автоматизации

Мы идём по рынку 1С и наблюдаем за людьми, которые бегают в поисках автоматизации. В один момент они останавливаются: прежде чем автоматизироваться, важно понять, готов ли к этому бизнес.

Пришли неподготовленные? Сейчас мы вас разденем! Собственники бизнеса, которые не были готовы, знают, как это бывает: как приходят ребята, как красиво они танцуют, показывают классные презентации, а потом выставляют большие счета. Они делают то, что вам не нужно. Проверить это невозможно, потому что вы не специалисты. По итогу 70% проектов уже подписаны, оплачены и актами закрыты. Результата нет. Только в этот момент вы начинаете задумываться: “А какой планировался результат?”.

“К автоматизации можно подготовиться. К автоматизации нужно подготовиться. Нельзя автоматизировать бизнес, если он не готов. Нельзя предъявлять претензии тем, кто делает автоматизацию, если на старте не было готовности” — Сергей Мироненко, собственник группы компаний “Авиант”.

Как понять, что бизнес готов к автоматизации? Рассмотрим алгоритм действий.

№1 Оценка собственной готовности и готовности бизнеса

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

“Сформулировать задачу для автоматизации невозможно, если я не понимаю и не представляю процесс, который планирую автоматизировать. Это является центральным требованием цифровизации и автоматизации бизнеса” — Сергей Мироненко, собственник группы компаний “Авиант”.

Есть 2 варианта:

1. Автоматизация, направленная на сокращение операционных затрат компании. Рассмотрим простой пример. Изначально было 20 человек, выполняющих определённые операции. Мы оцифровали эти действия, автоматизировали их. Потребность в 20 сотрудниках исчезла. Теперь нужно 2 человека вместо 20. Раньше заработную плату начисляли 20 людям, сейчас — двоим.
2. Автоматизация с целью ускорения реакции. Изначально мы разбирали заказы в течение 3 дней. За счёт применения алгоритмов, которые дублируют действия людей, заменяют их, процессы ускорились. Сейчас мы разбираем заказы не 3 дня, а 2 часа. Соответственно, можем обработать большее количество заказов.

Каждый из вариантов автоматизации предполагает сокращение издержек. Нужно понимать, в каком конкретно месте оно произойдёт.

“Если я понимаю, какие бизнес-участки и операции могут быть подвержены такому качественному изменению, чтобы на выходе затраты на эти операции уменьшились, я готов к автоматизации данного участка” — Сергей Мироненко, собственник группы компаний “Авиант”.

№2 Выбор исполнителя

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

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

“Они делали это вчера и хотят делать это сегодня. Такие подрядчики не предлагают варианты, не входят в обсуждение, не модерируют процесс выбора. Они хотят приложить минимум усилий и продать вам те компетенции, которые у них есть сегодня” — Сергей Мироненко, собственник группы компаний “Авиант”.

Передать ответственность за принятие решения специалистам по автоматизации — это ошибка. Остаётся 2 варианта, каждый из которых с точки зрения эффективности является правильным:

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

Как проверить эксперта? Сделать это просто. Эксперт отличается от специалиста тем, что предлагает несколько вариантов решения задачи.

“Чтобы это проверить, я разработал простой тезис. Эксперт отличается тем, что он организует круглый стол, собирает заинтересованных со стороны клиента лиц и выбирает оптимальное решение. Проведение такой встречи, такой модерации — это и есть работа эксперта. На выходе предприниматель может совершенно спокойно, вменяемо и рассудительно принять решение, твёрдое и жёсткое. Относительно его можно строить бизнес-процессы, потому что это решение меняться не будет. Все остальное — манипуляции” — Сергей Мироненко, собственник группы компаний “Авиант”

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

№3 Состояние Дзен

“Я называю это состоянием Дзен. Тогда бизнес может спокойно отнестись к процессу автоматизации. Крайне не рекомендуется заниматься автоматизацией, когда бизнес страдает, а показатели падают. Также не нужно этого делать, когда бизнес резко и быстро растёт” — Сергей Мироненко, собственник группы компаний “Авиант”.

Автоматизация — процесс, похожий на заливку бетона. Когда материал остывает, чтобы его сломать, требуются определённые усилия. В условиях роста бизнес-процессы меняются, причём достаточно быстро. Компания должна быть гибкой. При росте показателей эффективности даже на определённых участках рекомендуется использовать гибкую автоматизацию, то есть не склоняться лишь к одному решению, которое предложил подрядчик, а пользоваться теми инструментами — платными, бесплатными, — которые закрывают конкретные задачи. Например, Google Таблицы, где отчёты можно менять хоть каждую неделю. Пока бизнес растёт, лучше всего пользоваться именно такими инструментами.

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

Если ваш бизнес находится в состоянии Дзен, планово растёт, он готов к автоматизации. Это управляемый, а не взрывной рост. Плановые снижения с понятными факторами, не влияющими на вашу модель.

Заключение

Итак, компания готова к нормальному, спокойному процессу автоматизации, когда есть:

1. Собственная готовность и готовность бизнеса. Он не сопротивляется изменениям.
2. Взаимодействие с экспертами. Выбор правильных моделей.
3. Качественно принятые регламенты и политики, которые проработаны вместе с экспертами, приняты на верхнем уровне и уже действуют в компании.

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

Мифы, которые кружатся вокруг ИТ-отрасли — 1 из 10 проектов взлетает, а 9 остаются в убытке — лишь подтверждают то, что 9 компаний были не готовы. Это можно продиагностировать на старте. Диагностика содержит всего 3 аспекта и занимает 1 рабочую неделю. Если компания не готова, необходимо перейти к реализации рекомендаций по подготовке к автоматизации. Это целый процесс, по факту прохождения которого можно приступать к автоматизации.

Проблема рынка автоматизации — рынка 1С, в частности — заключается в том, что 90% компаний затевают этот процесс, абсолютно к нему не подготовленными. Ни по одному из пунктов готовности нет. Они нанимают подрядчиков, бегают по рынку и верят в то, что могут найти волшебника в голубом вертолёте, который прилетит и угостит их эскимо. А в итоге, к сожалению, прилетают орки без вертолёта и эскимо, но с огромными пиками, которые насаживают в мягкие места заказчика. Заказчик удивлённо смотрит: “Почему же?”. Все объясняется очень просто: готовности к автоматизации не было.

К автоматизации можно и нужно подготовиться. Мы знаем, как это сделать. И мы вас подготовим. Это займёт не годы, а 2-3 месяца в зависимости от объёма предприятия. Автоматизируйте свой бизнес вовремя!

Оценка готовности компании к автоматизации

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

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

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

Для этого необходимо понять:

• Какую цель ставит перед собой компания, стартуя проект автоматизации. Чего на самом деле она хочет достичь и какие задачи решить за счет внедрения информационной системы;
• Кто является инициатором проекта, насколько высшее руководство заинтересовано в проекте и чего оно ждет от этого проекта. Какие проблемы на самом деле волнуют первое лицо (ведь в итоге генеральный директор или собственники будут спонсорами проекта);
• Какие бизнес-процессы существуют в компании. Все ли бизнес-процессы, которые должны в ней быть (с учетом специфики бизнеса и структуры управления), есть на самом деле;
• Насколько эти бизнес-процессы выстроены и автоматизированы, степень текущей автоматизации: только учет, учет и управление, наличие сложных аналитических данных;
• Насколько проработаны в компании методики и регламенты, задающие правила работы: учетная политика, бюджетная модель, методика расчета себестоимости и т.п.

Какие работы включает в себя оценка управленческой готовности компании к автоматизации?

• Уточнение реальных целей проекта автоматизации. Согласование с заказчиком задач, которые решаются автоматизацией и задач, требующих внутриорганизационных изменений;
• Верхнеуровневый анализ существующих бизнес-процессов и связей между бизнес-процессами. Определение основных и смежных процессов, которые необходимо включить в контур проекта;
• Анализ степени выстроенности бизнес-процессов, наличие и проработанности методик и правил выполнения бизнес-процессов. Определение необходимого состава работ проекта, в т.ч. работ, не связанных с автоматизацией.

Продолжительность первоначальной оценки как правило составляет от 1- 2х недель до месяца.

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

Что вам может дать такая услуга:

• Повысить соответствие содержания работ и контура проекта требованиям и специфике предприятия. Тем самым, снизить риски, связанные с отсутствием необходимых методик, неформализованностью требований к будущей системе, появлению неучтенных требований на последних этапах проекта;
• Снизить риски срыва сроков проекта за счет появления задач, требующих проработки специалистами заказчика, и не заложенных в график проекта;
• Более точно определить состав команды и необходимые компетенции с обеих сторон. Тем самым обеспечить необходимое качество результатов;
• И самое главное — повысить успех проекта за счет того, что требования к результатам проекта и к самой системе будут сформулированы полно и корректно, однозначно понятны заказчику и вашим специалистам.

• Звоните+7 (985) 970-58-78
• Пишитеorg@cons-dir.ru
• Скайпskype_cons_dir

Как подготовить компанию к автоматизации: 6 уровней

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

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

Готовность компании к автоматизации

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

1. Отсутствующий уровень.

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

2. Начальный уровень.

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

3. Управляемый.

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

4. Определяемый.

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

5. Измеряемый.

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

6. Оптимизируемый.

Теперь бизнес-процесс не нуждается во внешнем вмешательстве и работает на всех уровнях самостоятельно.

Выводы

В результате можно увидеть, как бизнес из хаотичного явления переходит в отработанные процессы, которые теперь готовы к автоматизации. Чтобы модель «зрелости бизнес-процессов» наглядно показала, на каком этапе находится компания, важно определить не уровень бизнеса в целом, а степень зрелости каждого отдельного процесса, которые есть в организации. Только так можно увидеть, что требует доработки, а что уже готово к автоматизации.

А с автоматизацией бизнеса уже мы вам поможем.

Автоматизация vs оптимизация

Анализ и оптимизация бизнес-процессов становятся все более востребованными в проектах автоматизации, а с массовым переходом с 1С: УПП на 1С:ERP эта задача станет еще более актуальной. О том, как собрать полную картину реальных потребностей вашего заказчика, исходя из логики его бизнес-процессов, на конференции Infostart Event 2021 Moscow Premiere рассказала Елена Иванова.

Меня зовут Иванова Елена, в прошлом Буравлева. Я не разработчик и не программист. Я бизнес-архитектор, консультант по управлению, руководитель проектов, связанных с консалтингом, который постоянно работает на стыке с автоматизацией бизнес-процессов. В проектах я занимаюсь тем, что готовлю компанию к внедрению информационной системы, которая должна поддерживать управленческие процессы. То есть, я занимаюсь выстраиванием системы управления, оптимизацией бизнес-процессов и через это – выходом на требования к будущей ИТ-архитектуре, которая, как правило, не ограничивается одной информационной системой, приходится создавать некое ИТ-пространство. Начинала я с классического консалтинга – уже более 20 лет работаю в этом направлении. Последние 15 лет я очень плотно работаю в совместных проектах на стыке с ИТ-отраслью. Причем, я стараюсь работать таким образом, чтобы мы заходили в проект вместе с командой, которая будет потом внедрять информационную систему. Потому что только так достигается синергия. Невозможно делать проекты, когда отдельно приходят консультанты, которые как-то описывают бизнес-процессы, выдают огромные “талмуды”, потом приходит отдельная внедренческая команда, которой нужны совсем другие данные, получает эти документы с некими моделями бизнес-процессов, смотрит на них и заново начинает обследование. 6 лет я проработала внутри фирмы «1С», где возглавляла направление 1С:Консалтинг и занималась его развитием. Это дало мне колоссальный опыт понимания того, как взаимосвязаны ИТ и классический консалтинг.. Сейчас я фриланс, сотрудничаю с ИТ-компаниями и отдельными ИТ-командами в совместных проектах. Поэтому готова поделиться своим опытом, рассказать о подводных камнях, граблях, на которые приходится наступать, и о некоторых инструментах и подходах к выстраиванию правильной логики такого проекта, чтобы этих граблей избежать. Мой сегодняшний доклад будет посвящен теме автоматизации, оптимизации и стыка этих двух областей применительно к процессам управления. Надеюсь, эта информация повысит вашу осознанность на этапах входа в проект, сбора и формализации бизнес-требований, и вы не наступите на те грабли, на которые периодически наступает все, кто занимается ИТ проектами. Прежде чем начать, я хочу задать пару вопросов:

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

Вот об этом мы с вами сейчас и поговорим.

Взгляд ИТ-аналитика на цели и задачи проекта

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

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

Но, по сути, мы в этих проектах отвечаем на вопрос «ЧТО?», плюс даем компании некий инструментарий, который отвечает на вопрос «КАК?»

Взгляд бизнес-заказчика на цели и задачи проекта

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

Бизнес хочет повысить бизнес-эффективность. А что такое бизнес-эффективность?

• Наш бизнес-заказчик – топ-менеджмент, который вас запускает в проект (а именно топ-менеджмент платит деньги за автоматизацию) – хочет оптимизировать бизнес-процессы, сократить ненужные операции. Да, под этим подразумевается автоматизация, но это еще и исключение дублирующих операций и дублирующих функций. Соответственно, эти операции и функции нужно каким-то образом закрепить за кем-то одним, чтобы одновременно три-четыре-пять разных сотрудников разных должностей не делали одно и то же.
• Естественно, бизнес очень хочет выработать сам или получить от вас какой-то Best Practice по различным методикам: расчета, анализа, трансформации данных. Для принятия управленческих решений на основе этих данных.
• И, естественно, бизнес хочет более четко закрепить ответственность через автоматизацию – я с этим регулярно сталкиваюсь. Мне директор говорит: «Если у меня проблемы в компании, я хочу четко знать, с кого спросить. Я хочу понять, кто у меня отвечает за ввод именно этого показателя, за формирование тех или иных аналитик. Если у меня вдруг где-то какой-то KPI “сбоит”, я хочу знать, с кого спросить за то, что у меня этот KPI отклонился от моего целевого значения».

Соответственно, бизнес, когда заказывает этот проект автоматизации, хочет получить ответ на вопрос «ДЛЯ ЧЕГО» на уровне целей и смыслов. Поэтому правильнее всего – выстраивать логику проекта и сбор требований на входе именно от потребностей и целей бизнеса и предпосылок инициации этого проекта.

И здесь у нас возникает зона несоответствия.

Рост рынка оптимизации бизнес-процессов

Немного статистики. Подтверждением того, о чем я сейчас говорю, является аналитика по рынку – я периодически мониторю спрос на те или иные услуги в проектах ИТ и их долевое соотношение. На слайде представлены данные рейтингового агентства «Эксперт».

Данные по колонке за 2017 год я в свое время собирала еще для доклада на секции “1С:Консалтинг”. Если вы обратите внимание, то у нас с вами ИТ-разработка и ИТ-консалтинг – 33% и 26%. Все остальное – производственный, финансовый консалтинг, и некие еще “Прочие”.

А что у нас в 2020 году? У ИТ-разработки и ИТ-консалтинга до сих пор высокая доля, но она снижается по сравнению с общим спросом на разного рода услуги. А что растет?

• Финансовый консалтинг – сюда входит финансовый анализ, показатели финансово-хозяйственной деятельности, управленческая отчетность
• Производственный консалтинг – сюда входит оптимизация себестоимости, повышение скорости и качества производства продукции для удовлетворения спроса на рынке.
• И вот это – Прочее. И вы знаете, что удивительно? В этом «Прочем» есть такая зона, которая связана с консалтингом по выстраиванию оптимизации бизнес-процессов. Его почему-то отдельно не выделяют, но сейчас по данным того же TAdviser и рейтингового агентства «Эксперт» ежегодно прирост спроса на консалтинг в области совершенствования бизнес-процессов за счет автоматизации примерно 15% в год. Также в этот круг услуг входят KPI бизнес-процессов, нормализация данных и т.д.

Оптимизация бизнес-процессов становится популярной, потому что не все задачи решаются только за счет автоматизации.

Например, если мы с вами говорим о том, что у нас есть задача «Снизить издержки», мы должны:

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

Чтобы это автоматизировать, нам нужно:

• настроить методику оборачиваемости запасов;
• нам нужен сценарный подход к закупкам, чтобы в зависимости от вида номенклатуры мы оптимальным образом запускали этот процесс, сокращали ненужные действия и задавали жесткие алгоритмы – что и по каким правилам закупаем (под запас на склад, под заказ или еще каким-то образом).
• нам нужна правильная учетная политика, чтобы мы корректно считали структуру себестоимости, и т.д.

Если у нашего бизнеса стоит задача «Рост продаж». Для этого мы должны усовершенствовать:

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

Чтобы это автоматизировать, нам нужны:

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

Если бизнес говорит: «Я хочу за счет автоматизации повысить экономическую эффективность», мы сразу начинаем разговаривать о том, что:

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

Что нам для этого нужно?

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

И эти задачи не про автоматизацию.

Выход – комплексный (системный) подход

Когда вы приходите на проект, у вас есть два варианта:

• Либо бизнес вам это все выдает в готовом виде, по четким правилам, по четким формулам, чтобы вы могли загнать это в систему, предложить оптимальный инструмент решения этих задач;

• Либо бизнес ждет, что вы, как компания, которая обладает отраслевым опытом или опытом решения определенных задач, принесете ему Best Practice и скажете: «Ребята, вот формула, которая вас устроит». Либо каким-то волшебным образом за счет автоматизации поможете ему это все сформулировать, оцифровать, и в системе это как-то само появится.

Но чудес не бывает.

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

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

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

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

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

  Первый шаг – определить контур проекта и выделить процессы компании

  

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

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

  Классический инструмент – декомпозиция процессов.

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

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

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

  Второй шаг – количество и виды бизнес-процессов

  

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

  Тут у нас есть еще один подводный камень, с которым мы регулярно сталкиваемся. Есть понятие модификации. Это некая разновидность одного и того же процесса.

  Классический пример – процесс продажи. Казалось бы, один процесс. Ничего подобного. У нас, например, есть продажа ВИП-клиентам и есть продажа мелким клиентам. И они могут различаться.

  • Во-первых, за них могут отвечать разные отделы, как минимум. Это значит, что они уже по-разному организуют свою деятельность.
  • Во-вторых, ВИП-клиенты – это годовые контракты, резервирование товара под заказ клиента еще в производстве или на этапе закупки у поставщика. А у мелких клиентов – отгрузка со склада и оперативные заказы только при наличии остатков на складах.

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

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

  Каким образом это можно определить?

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

  

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

  Для этого есть классическая схема классификации на процессы базовые, вспомогательные и процессы управления.

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

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

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

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

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

  • Если у нас поставщики и потребители – внешние, значит, совершенно точно, это базовый процесс.
  • Если поставщики и потребители – внутренние, то это либо вспомогательный процесс, либо процесс управления (в зависимости от результата).

  Для каждого процесса – свой набор инструментов

  

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

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

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

  Пример проработки процессов

  

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

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

  Начинаем разбираться с процессами, исходя из поставщиков данных.

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

  Обратная история – потребители данных.

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

  Как с этим работать в проектах

  

  Чтобы работать с этим подходом в проектах, нужно изменить технологию работы с требованиями.

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

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

  Инструмент зависит от задачи

  

  Если вы это все понимаете, то, каким образом должна выстраиваться логика работы в такого рода проектах?

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

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

  И, в зависимости от того, с какой областью вы работаете, что ожидает заказчик, с чем вы сталкиваетесь на входе, вы предлагаете:

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

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

  Всегда ли нужна оптимизация?

  

  Оптимизация на проекте нужна не всегда.

  • Вполне можно проводить проекты автоматизации, когда у нас автоматизируется жестко регламентированная государством область – бухгалтерский учет, налоговый учет, кадровый учет. Там тоже, конечно, есть некоторые нюансы, но там есть более-менее жесткие правила, компании вынуждены им следовать.
  • Когда у вас цель проекта – первичная автоматизация, нужно просто обеспечить корректный первичный ввод данных. Не нужно тратить время на оптимизацию процессов, нужно предложить типовое решение, которое позволит сначала эти данные обеспечить. А уже потом, когда компания поймет, чего ей не хватает, заниматься оптимизацией.
  • Когда у нас есть какая-то изолированная область, не очень связанная с другой деятельностью, ее можно выделить в отдельный контур, для которого предложить типовое решение – например, «Управление автотранспортом». Там внутри, конечно, тоже есть зоны оптимизации, но при этом не нужно выстраивать сквозные бизнес-процессы, и общую аналитику со всей остальной деятельностью.
  • И еще очень важный момент из личной практики – не заходите никогда в оптимизацию и выстраивание деятельности, если компания только начинает свою работу. Потому что у нее еще нет никаких бизнес-процессов, они только начинают формироваться. Даже если компания предлагает вам использовать какие-то предыдущие наработки от другой компании, их придется адаптировать. Потому что есть корпоративная культура, специфика ментальности топ-менеджмента, среда, в которой эта компания работает. Это все будет накладывать определенные ограничения и трансформировать их бизнес-процессы. И если вы начнете помогать им выстраивать деятельность на этапе старта бизнеса, то у вас требования к этой деятельности и ее автоматизации в течение примерно пары лет будут меняться. Поэтому в этом случае лучше заходить с типовым решением,возможно с отраслевым решением, но с типовым. Годик-два компания должна стабилизироваться. Процессы “устаканились”, бизнес понял, что ему нужно, и после этого можно уже приходить с предложением оптимизации, чтобы уже повышать бизнес-эффективность.

  Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere.

  30 мая — 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на котором прозвучит 130+ докладов.

  Темы конференции:

  • Работа с данными: архитектура, интеграции, отчеты.
  • Программная инженерия.
  • Решения 1С: архитектура, учет и практические задачи.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.
  • Кейсы автоматизации на 1С

  Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

  Похожие публикации:

  1. Space что это
  2. Как играть в майн через впн
  3. Как открыть диск
  4. Почему гаррис мод вылетает