Айтишники – как бедные родственники. Денег не зарабатывают, но постоянно просят увеличить бюджет. Доказать плюсы автоматизации на своем птичьем языке у них не всегда получается. Польза от IT сводится к IPhone или Vertu, легкому навороченному ноутбуку, возможности писать письма, редактировать документы и участвовать в видеоконференциях.
Знакомо? Поверьте, все совсем не так. IT могут и должны выполнять задачи управления. Просто нужно знать, как это сделать. Если правильно организовать IT-архитектуру компании, то можно получить оперативный доступ к полной картине бизнеса, определить точки роста, создать условия для повышения эффективности процессов труда и производства. Важно понимать, что это целая взаимосвязь различных систем, работающих как единый механизм и влияющих друг на друга. Не стоит ждать качественных изменений от внедрения BI, если у вас нет KPI или единого хранилища. Это все равно, что ждать работы от сердца без кровеносной системы.
IT-архитектура для управления бизнесом строится на трех уровнях: стратегическом, тактическом и операционном, – в соответствии с логикой цикла Деминга (планирование-выполнение-проверка-анализ-корректировка).
Упрощенно ее можно нарисовать так:
Кликните, чтобы увеличить картинку.
Начинать внедрение архитектуры можно сверху, снизу или с двух сторон одновременно. Любое движение по этой схеме принесет компании пользу. Идя сверху, руководитель может структурировать методы управления предприятием, увидеть важные бизнес-процессы и приступить к их улучшению – например, повысить скорость обработки какой-нибудь операции. Здесь важно не увлечься написанием монументального труда по KPI и не заняться глобальным переделыванием всех существующих систем.
Двигаясь снизу, важно не потерять за деревьями лес, поэтапно дотягивать технические возможности предприятия до требований методологии. В таком случае реализацию лучше начинать с наиболее приоритетных задач. Они формулируются в упрощенном варианте, дорабатываясь от итерации к итерации по комментариям и пожеланиям. Корректировать требования на основе прототипа получается проще, чем исходя из теоретических изысканий. Теперь чуть подробнее о том, как это реализуется.
Планирование
Планирование начинается со стратегического уровня, выраженного в целевых показателях (KPI) для всего предприятия. Обычно это делается в терминах сбалансированных показателей (BSC) или близкой к нему методологии.
При переходе на тактический уровень, производится декомпозиция целевых планов по подразделениям на основе выбранной модели предприятия. Привычный для многих способ – бюджет. Он базируется на финансовых показателях. При этом рекомендуем помнить о целях, относящихся к другим перспективам BSC: клиенты, внутренние процессы, обучение и развитие. Так или иначе, процесс планирования завершается определением целевых показателей эффективности для подразделений. Логично, когда к ним привязаны системы материального поощрения руководителей и сотрудников этих подразделений.
Выполнение поставленных целей
Далее на операционном уровне реализуются бизнес-процессы, а на тактическом – их корректировка для достижения плановых KPI. Это наиболее сложная организационная и техническая части архитектуры. Большинство используемых на предприятии информационных систем – транзакционные, то есть ERP-системы, которые обеспечивают выполнение бизнес-процессов.
Из нашего опыта: лучше отделить управление бизнес-процессами (BPM) от самих транзакционных систем и вывести его в отдельный модуль. Это позволяет формализовать бизнес-процессы, унифицировать их, измерять по ним показатели эффективности для всех уровней управления. Этот логичный шаг обычно вызывает мощное сопротивление со стороны сотрудников предприятия и специалистов по внедрению, уверенных, что именно их система 1С, SAP, Oracle (нужное подчеркнуть) позволяет сделать все намного удобнее. Процесс выделения может проходить менее болезненно, если на предприятии действует несколько информационных систем, хотя и здесь владелец основной системы стремится доминировать над остальными.
Правила реализации:
1. Выделить BPM из остальных транзакционных систем.
2. BPM должна реализовывать сценарии обслуживания, а не быть статичной.
3. Понятный и простой интерфейс для BPM.
4. Сама система должна быть инструкцией, нормативным документом и обучающим тренером.
5. Система должна предоставлять пользователю варианты решения ситуации, а не информацию. Если вариантом решения является информация, то она должна быть полезной на конкретном этапе выполнения бизнес-процесса.
6. Все процессы в системе могут быть измерены и отслежены. Это создает почву для улучшений и повышения эффективности.
Для обеспечения взаимосвязи между различными бизнес-процессами в организации используется интеграционная шина. Она является своеобразным мостом между разрозненными островами информационных систем, позволяя создать единую информационную среду компании. Изменения показателей в одной базе автоматически и гарантированно находят отражение во всех остальных информационных системах. Это позволяет исключить дублирование информации и обеспечивает ее актуальность для всех бизнес-процессов.
К общей шине с помощью специальных адаптеров подключаются транзакционные системы и интерфейс оператора. Он необходим для фиксации управленческих решений. Например, для подтверждения операции, или когда данные проще ввести руками, чем встраивать в информационную систему. В идеале, взаимодействие с человеком должно быть отделено от транзакционных систем. На практике условие не всегда выполняется, так как требует существенных усилий по доработке информационных систем, не приспособленных для этого.
Хранилище данных транзакционных систем традиционно отделяют от хранилища отчетных, чтобы «сырые» данные прошли процедуру очистки. Когда про это забывают, в отчетах появляются ложные данные, подрывающие доверие ко всей системе отчетности и аналитики. Для снижения риска недостоверности ввода мы советуем, чтобы за каждую «цифру» в транзакционных системах отвечал конкретный сотрудник.
Анализ и корректировка
После реализации бизнес-процессов наступает пора последовательного сравнения полученных результатов с плановыми показателями эффективности и принятия решения для уменьшения расхождений. Это время BI-систем.
Руководитель компании должен получить на своем столе приборную доску (дашборд), на которые будут выведены наиболее важные показатели, существенные отклонения. Это некий «светофор» – индикатор для принятия решений о корректировке. Этой же цели должна служить и возможность в режиме онлайн детализировать любой отчет.
Данные для этого берутся из модуля анализа данных, который содержит два вида отчетов:
- регламентированные, отражающие результаты план-факт показателей эффективности для всех подразделений;
- и аналитические, позволяющие изучать причины отклонений.
Советы руководителю:
1. Набраться мудрости по этой теме можно в книгах: «Управление эффективностью бизнеса» Евгения Духонина, Дмитрия Исаева и др. или «Система управления эффективностью бизнеса» Нияза Абдикеева и Ольги Китовой.
2. Оцените, какие элементы из существующей схемы у вас уже есть.
3. Начните двигаться к идеалу, постепенно внедряя наиболее важные для вас модули. Каждый шаг будет приближать вас к мечте, и приносить пользу бизнесу.
4. Почувствуйте пользу от IT.
Редактор рубрики «IT для бизнеса» – Сергей Соловьев
Источник
изображения в анонсе: pixabay.com
Людям свойственно стремться к идеальному миру :)
В идеальном ИТ-мире все процессы и связи описаны, диаграммы построены, а каждая финансовая транзакция немедленно обновляет карту сбалансированных показателей. Можно позавидовать руководителю такой компании: он сидит в кабинете, где вместо стен огромные экраны с дашбордами, в них - отражение всей деятельности организации. Легким движением руки по планшету руководитель не только исследует причины снижения отдельных показателей, но и строит предсказательные модели на будущее.
ИТ-шники тоже чувствуют себя счастливыми: требования по оптимизации процессов приводят к необходимости изменить несколько стрелочек на диаграмме бизнес-процессов. Все остальное происходит автоматически: изменяется модель данных в хранилище, обновляется репозитарий сервисов и генерируются новые интерфейсы пользователей. Да что уж там - даже реверс-инжениринг работает: ручные изменения в модели данных, коде и интерфейсах гармонично и бесконфликтно укладываются в ИТ-систему.
Правда, на практике все происходит несколько иначе.
BPM-системы внедряются не быстро, и при этом, как правило, закрывают лишь некоторую часть бизнес-процессов. Благие желания унифицировать подход к разработке ИТ-ландшафта разбиваются о необходимость покупки бизнесу очередной нишевой програмки для выполнения ограниченного набора функций. Скопление таких программок тем больше, чем старше организация. Затраты на поддержание и интеграцию множества программулек могут зашкаливать, но это обычно в расчет не принимается. Приобретение же единой промышленной ИТ-платформы воспринимается обычно как ''очень дорого''''
И это еще больше отдаляет нас от идеальной архитектуры...