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

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

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

Начинала я с классического консалтинга – уже более 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.