Унификация бизнес процессов что это

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

Для последовательного раскрытия обозначенной темы в предлагаемой статье применяется один из любимых приемов авторов – «4П».

Предпосылки

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

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

В какой-то момент возникла острая потребность в глобальном осмыслении всех применяемых лучших практик для формирования экспертного подхода (как в технической, так и в теоретической области), ведущего к эффективным процессам предоставления и поддержки услуг. И тут хорошим подспорьем послужило применение основ case-management. Этот рассказ будет отчасти о результатах наших последних экспериментов в области динамического управления процессами.

Панацея

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

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

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

Для примера можно выделить некоторые из задач внедрения, которые вызывали наибольшие опасения:

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

Принцип

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

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

Таким образом, конфигурация Naumen Service Desk работает на взаимодействии двух концептуальных областей сервисного и процессного подхода, где:

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

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

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

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

Какие настройки определяются в услуге:

1. Информация: название, описание, предназначение, ограничения, справочники.
2. Структура услуги и ее составных частей (компонентов).
3. Определение места услуги в ресурсно-сервисной модели (связи услуги с поддерживаемыми услугами, а также теми, которые обеспечивают работу текущей услуги).
4. Определение регламентного времени обслуживания (SLA), графиков поддержки, часовых поясов, по которым ведется обслуживание.
5. Определение параметров планово-профилактических работ по услуге.
6. Определение ролевой модели для услуги (управляющие, исполняющие, согласующие и т. п. роли).
7. Набор возможных видов деятельности по предоставлению и поддержке услуги (виды запросов и какие процессы могут быть исполнены в рамках услуги).

Процессный подход

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

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

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

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

Состав основных процессов

Для каждого из процессов определены:

1. Цели;
2. Политики;
3. Виды деятельности;
4. Интерфейсы со смежными процессами;
5. Роли и ответственность за виды деятельности;
6. Метрики.

Пример шагов процесса

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

«Любую многоходовую, сложную и ветвистую последовательность активностей можно выстроить в виде пирамид услуг и запросов. При этом выполнение каждого из запросов очень простое и не вызывает затруднений у специалистов», – уточняет Александр Нагорный, ITIL Expert, руководитель группы процессного проектирования.

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

Масштабирование

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

• Что будет, когда пойдем развертываться в региональных филиалах?
• Что будет, если с нового года в нашем составе появится новая организация со своей отдельной структурой, каталогом, политиками, культурой, как мы поделим систему и процессы на двоих/троих/семерых/сотню…?
• Как быть, если потребуется внедрить новые процессы?
• Как быть, если появится множество новых подрядчиков со своими ITSM-системами?

Учитывая перспективы роста, с первых этапов внедрения важно абстрагироваться от приставки «ИТ».

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

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

Настройки услуги могут быть локализованы до подразделения и расположения

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

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

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

Примеры ситуаций, в которых используются бизнес-правила:

Определение ответственных при обработке запросов

Например: 1. Если ты сотрудник московского офиса и у тебя неисправен компьютер, то восстановить работоспособность тебе поможет специалист из московского подразделения службы поддержки. 2. Если же ты сотрудник московского офиса, но находишься в рамках деловой поездки в Санкт-Петербурге, то тут уже на помощь придет специалист из местного подразделения.

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

Определение участников и последовательности согласований

Например: 1. Если тебе нужно получить ноутбук в деловую поездку, то будь добр, согласуй такое решение со своим руководителем. 2. Если же тебе необходимо получить выгрузку информации из одной из систем, то одним руководителем не обойтись. В согласовании последовательно или параллельно будут участвовать как руководитель, так и другие участники, мнение которых также следует учитывать. Это может быть как владелец системы, так и представители службы безопасности.

Определение последовательности выполнения работ

Например: 1. При организации рабочего места новому сотруднику в Москве необходимо выполнить последовательность работ, к примеру, установить оборудование, произвести подключение к Интернету, сформировать учетную запись. На основании бизнес-правила будут созданы параллельно или последовательно запросы на выполнение соответствующих видов деятельности. 2. А вот в Екатеринбурге каталог услуг не ограничен только ИТ-областью, в процессе также участвуют и представители АХО, поэтому, в аналогичной ситуации подключатся и электрики, для проверки или организации подключения к электросети.

В данных примерах за счёт преднастроенных бизнес-правил в зависимости от локации определяется состав шагов по реализации.

Определение регламентного времени выполнения запросов

Например: Служба технической поддержки централизованная и находится в Москве. Мы можем пообещать производить замену картриджа в принтере за 2 часа астрономического времени сотрудникам подразделений, которые находятся в том же офисе. А вот сотрудникам филиалов из Подмосковья – гарантированное время выполнения работ – не менее 8 рабочих часов, а то и 16.

В данных примерах за счёт преднастроенных бизнес-правил в зависимости от подразделения, определяется время исполнения и режим обслуживания.

В общем, перекладываем все условия и решения в правила, – и настанет счастье человеколюбивого сервисного управления!

Послесловие

Основной принцип конфигурации Naumen Service Desk – единая концепция, в основе которой – адаптивные управляющие бизнес-правила. Это и есть тот искомый “КЛЮЧ” к успеху и эффективности.

Вам подойдет эта конфигурация, если:

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

1. Любую специфику организации можно реализовать посредством гибкого каталога услуг.
2. Унификация и стандартизация обеспечивается посредством использования единых взаимосвязанных процессов, простых и понятных участникам.
3. Масштабирование предусмотрено на любом этапе развития организации посредством применения адаптивного управления в бизнес-правилах.
4. Принцип делегирования функций помогает точно определить оптимальную ролевую модель, с максимальным использованием локальной экспертизы.
5. Удобство портала самообслуживания, который повышает настроение и удовлетворенность получателей услуг до максимума!

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

• Блог компании Naumen
• IT-стандарты
• Управление проектами
• Управление продуктом
• IT-компании

Источник: habr.com

Об унификации описания бизнес-процессов

В качестве первой установочной концепции озвучивалась идея о принадлежности «Работ» одному классу объектов, обладающих одинаковым набором свойств и поведением. Для чего это нужно? Прежде всего, для того чтобы различные «Работы» могли общаться друг с другом на одном языке. Только в этом случае бизнес-процесс может быть открытой системой.

О необходимости придерживаться идеологии открытых систем при проектировании модели бизнес-процессов как необходимом условии реализации принципа последовательных модернизаций писалось не раз [1, 2]. Только открытым системам свойственен низкий уровень издержек при сопровождении и доработках.

На моделирование бизнес-процессов, согласно методологии IDEF и первым ее интерпретациям, был ориентирован стандарт IDEF3. Основным его отличием от стандарта функционального моделирования IDEF0 была возможность задавать последовательность «Работ» с помощью дуг и условия на последовательность исполнения «Работ» с помощью логики «перекрестков» (синхронные и асинхронные ИИЛИ, исключающее ИЛИ).

Предполагалось, что проектировщик, не вдаваясь в описание логики взаимодействия «Работ», разработает функциональную IDEF0-модель до определенного уровня декомпозиции «Работ», а затем на нижних уровнях перейдет на моделирование бизнес-процессов в соответствии со стандартом IDEF3, отображая уже логику взаимодействия «Работ». Поскольку уровень декомпозиции IDEF0-модели, на котором осуществляется переход на стандарт IDEF3, определяется проектировщиком субъективно, то говорить о какой-либо универсальности представлений бизнес-процессов при таком подходе не приходится.

Как было показано, предлагаемая конкретизация положений IDEF0 в части описания событий и, следовательно, логики, не уступает по функциональности стандарту IDEF3. Так, в рамках ресурсной концепции управления организацией дуги в стандарте IDEF0 также могут показывать последовательность исполнения «Работ», а условия исполнения «Работ» задаются событиями «Поступление Ресурса».

Возможно, это явилось одной из причин, почему в популярном инструментарии BPwin диаграммы, поддерживающие стандарт IDEF0, называются Business Process Diagram. Одно можно сказать точно: одновременное использование стандартов IDEF0 и IDEF3 в рамках одного проектного процесса никак не способствует однозначному пониманию понятия «бизнес-процесс» в системе стандартов IDEF.

Что такое «Работа», интуитивно ясно. Сложнее обстоит дело с бизнес-процессом, описываемым «Работами». В статье [3] собрано 10 различных определений бизнес-процесса и показано, насколько сложен логико-лингвистический анализ определений бизнес-процесса на смысловую непротиворечивость; там же приводится авторское определение.

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

1. На вход бизнес-процесса поступают с выходов процессов-контрагентов ресурсы, которые преобразуются в бизнес-процессе в другие виды ресурсов, поставляемые контрагентам. 2. Все бизнес-процессы в организации объединены одной задачей — оказанием услуг друг другу на основе анализа запросов о поставке услуг. В частности, услугой может быть изготовление и поставка продукта.

3. Оказание услуг друг другу бизнес-процессы осуществляют согласно единой процедуре. На рис. 1. представлена универсальная IDEF0-модель бизнес-процесса, показывающая сущность интерфейсов «Работы»; как правило, проектировщики бизнес-процессов при их моделировании ее не раскрывают.

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

В этом случае желательно «принудительно» создавать сначала промежуточную IDEF0-диаграмму, на которой изображены «Работы»: входные и выходные интерфейсы бизнес-процесса и «Работа», отражающая сущность бизнес-процесса (ею обычно ограничивается неопытный проектировщик). Этого можно не делать только в случае, если проектировщиком осознанно отсутствие необходимости разрабатывать интерфейсы бизнес-процессов.

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

Один из них представляет бизнес-процессы в виде триады «Работ»: «Анализ реакции внешней среды», «Моделирование», «Воздействие на внешнюю среду». Данная идея изложена в [1] и основана на предположении, что организация — это система процессов «рефлексии». Важнейшим элементом является «Моделирование».

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

Моделирование — «Работа», отвечающая за непосредственное преобразование поставляемых бизнес-процессом «Ресурсов» и формирование новых «Ресурсов», поставляемых другим бизнес-процессом. Другой важнейшей функцией этой «Работы» является планирование (или программирование) поставок «Ресурсов» другим бизнес-процессом. План поставок строится для рассматриваемого бизнес-процесса с использованием модели его внешней среды (скажем, на основе заявок на поставку ресурсов). Входным интерфейсом бизнес-процесса является «Анализ реакции внешней среды» (т.е. «Работа», обеспечивающая на основе модели внешней среды и правил наблюдения «фильтрацию» поступающих «Ресурсов» и формирование необходимых спецификаций «Ресурсов», требуемых для исполнения «Моделирования»). Выходным интерфейсом бизнес-процесса является «Воздействие на внешнюю среду» (т.е. «Работа», осуществляющая поставку «Ресурсов» контрагентам на основе плана поставок, а также направляющая отчеты о поставках «Моделированию»).

Ограничение

Для продолжения скачивания необходимо пройти капчу:

Источник: studfile.net

Первые шаги к автоматизации документооборота в холдингах. Унификация и оптимизация бизнес-процессов

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

Автоматизация позволяет головной организации холдинга контролировать деятельность дочерних юридических лиц, влиять на выполнение бизнес-процессов, анализировать получаемые данные, производить планирование деятельности каждого из юридических лиц и холдинга в целом на перспективу. Безусловно, положительных моментов при внедрении СЭД много, но с чего начать?

Первый шаг после принятия решения о внедрении СЭД

Ошибается тот, кто считает, что достаточно выбрать для холдинга подходящую СЭД и вопрос решен.

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

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

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

Организационная структура холдинга

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

Итак, в предыдущей публикации мы уже говорили о том, что холдинг — это «. вертикально интегрированное объединение юридических лиц, основанное на экономической субординации.. .»*.

Поскольку в холдинге мы имеем дело не с одним юридическим лицом, а с несколькими, к тому же неким образом связанными между собой, то и организационная структура холдинга имеет свои отличительные особенности. Безусловно, каждое юридическое лицо холдинга имеет своего руководителя и все стандартные подразделения (кадровое подразделение, бухгалтерию, службу ДОУ, юридический отдел и т. д.), а управление такими подразделениями осуществляется по принципу линейного руководства (рис. 1)

Рис. 1. Схема линейной организационной структуры управления

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

Функциональное руководство подчиненными подразделениями в холдинге осуществляется следующим образом: руководитель направления является функциональным руководителем в головной организации, а функциональные подчиненные — руководители профильных подразделений в дочерних обществах холдинга. По сути, функциональная структура строится внутри холдинга, объединяя руководителя и функциональных подчиненных, которые одновременно являются сотрудниками головной организации и дочерних обществ.

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

Пример организации функционально-линейного управления в холдинге приведен на рис. 2.

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

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

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

Бизнес-процессы холдинга: зачем надо перестраивать (оптимизировать) бизнес-процессы?

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

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

● отсутствие подготовленного персонала, менеджеров, которые смогут организовать и взять под контроль вопросы построения внутренних бизнес-процессов, добиться нужного результата;

● отсутствие знаний в этой области у руководства компании;

● отсутствие в компании средств, необходимых для оптимизации и автоматизации процессов;

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

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

Отличительные особенности документопотоков холдинга

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

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

Для наглядного примера приведем схему уровней создания распорядительных документов холдинговой компании (рис. 3).

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

Текст такого приказа может выглядеть следующим образом:

1. Утвердить и ввести в действие форму финансового отчета предприятий холдинга (приложение № 1 к настоящему приказу).

2. Руководителям финансовых подразделений предприятий холдинга в срок до 01.03.2013 предоставить в Финансовый департамент Управляющей компании отчеты в соответствии с утвержденной формой. Ответственные: управляющие директора предприятий холдинга.

3. Контроль за исполнением настоящего приказа возложить на директора Финансового департамента Управляющей компании.

Таким образом, схема движения распорядительного документа управляющей компании холдинга будет выглядеть примерно так (рис. 4):

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

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

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

Основные аспекты при выборе СЭД для холдинга

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

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

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

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

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

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

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

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

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

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

Однако правильно проведенный процесс выбора СЭД еще не означает положительного результата при реализации проекта.

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

Источник: ecm-journal.ru