Первые шаги к автоматизации документооборота в холдингах. Унификация и оптимизация бизнес-процессов
![Первые шаги к автоматизации документооборота в холдингах. Унификация и оптимизация бизнес-процессов](/files/covers/746460d8-c0e0-4e04-a89b-6b18adc96577.jpg)
Для руководства холдинга очень важным является наличие гибкого механизма управления, позволяющего быстро и эффективно руководить деятельностью каждого сотрудника, каждого подразделения, каждой дочерней организации и холдинга в целом.
Автоматизация позволяет головной организации холдинга контролировать деятельность дочерних юридических лиц, влиять на выполнение бизнес-процессов, анализировать получаемые данные, производить планирование деятельности каждого из юридических лиц и холдинга в целом на перспективу. Безусловно, положительных моментов при внедрении СЭД много, но с чего начать?
Первый шаг после принятия решения о внедрении СЭД
Ошибается тот, кто считает, что достаточно выбрать для холдинга подходящую СЭД и вопрос решен.
Хочу сказать, что начинать стоит совершенно с другого вопроса, а именно с оптимизации, изменения, выстраивания организационной структуры, бизнес-процессов, документопотоков.
Почему предлагаю решать вопрос именно в таком порядке? Потому что проще и правильнее производить автоматизацию понятных и корректно построенных процессов, чем автоматизировать беспорядок. Построить процессы без четкой организации труда, разграничения полномочий сотрудников и руководителей невозможно.
Нужен быстрый обмен актами, счетами и другими юридически значимыми документами? Воспользуйтесь специальным решением для холдинговых компаний! |
Организационная структура холдинга
Сразу оговорюсь, что построение, оптимизация организационной структуры холдинга - это компетенция акционера и руководства головной организации, однако сотрудники службы ДОУ должны четко представлять принципы ее построения с целью определения зоны компетенции того или иного руководителя, организации работы с документами, правильной настройки документопотоков.
Итак, в предыдущей публикации мы уже говорили о том, что холдинг - это «...вертикально интегрированное объединение юридических лиц, основанное на экономической субординации.. .»*.
Поскольку в холдинге мы имеем дело не с одним юридическим лицом, а с несколькими, к тому же неким образом связанными между собой, то и организационная структура холдинга имеет свои отличительные особенности. Безусловно, каждое юридическое лицо холдинга имеет своего руководителя и все стандартные подразделения (кадровое подразделение, бухгалтерию, службу ДОУ, юридический отдел и т. д.), а управление такими подразделениями осуществляется по принципу линейного руководства (рис. 1)
Рис. 1. Схема линейной организационной структуры управления
Вместе с тем для руководства холдинга очень важным является наличие гибкого механизма управления, позволяющего быстро и эффективно руководить деятельностью каждого сотрудника, каждого подразделения, каждой дочерней организации и холдинга в целом. Такой механизм подразумевает возможность проведения централизованной политики управления холдингом в целях повышения эффективности деятельности, для достижения определенного уровня прибыли, удержания определенной доли и уровня продаж на рынке и т. д. Для этого на практике в холдингах часто в комплексе с принципом линейного управления применяется принцип функционального построения корпоративной структуры. При этом особое внимание уделяется правильному определению и разграничению зон ответственности (исключается дублирование функционала).
Функциональное руководство подчиненными подразделениями в холдинге осуществляется следующим образом: руководитель направления является функциональным руководителем в головной организации, а функциональные подчиненные - руководители профильных подразделений в дочерних обществах холдинга. По сути, функциональная структура строится внутри холдинга, объединяя руководителя и функциональных подчиненных, которые одновременно являются сотрудниками головной организации и дочерних обществ.
Приведем пример: руководитель финансового подразделения управляющей компании, с одной стороны, подчиняется своему непосредственному руководителю (линейное подчинение), а с другой стороны, может являться функциональным руководителем по отношению ко всем руководителям финансовых подразделений дочерних обществ холдинга и управлять их деятельностью, оказывать влияние на процессы управления финансами во всех юридических лицах холдинга (функциональное руководство), планировать развитие, заниматься автоматизацией бухгалтерского и управленческого учета и т. п.
Пример организации функционально-линейного управления в холдинге приведен на рис. 2.
Таким образом, на практике в холдинге один и тот же руководитель или сотрудник «включается» как в линейную, так и в функциональную структуру, т. е. образуется матричная структура управления.
Производственное подразделение на подобных схемах также присутствует и является подчиненным звеном технологического и управляющего блока.
Вместе с тем необходимо помнить, что холдинг развивается постепенно, поэтому и организационная структура, зоны ответственности могут в процессе его развития претерпевать значительные изменения.
Бизнес-процессы холдинга: зачем надо перестраивать (оптимизировать) бизнес-процессы?
Мы помним, что холдинги развиваются постепенно. При этом в процессе развития могут меняться приоритеты в организации управленческой деятельности.
В какой-то период развития холдинга, например, большее внимание может уделяться процессам и подразделениям, приносящим прибыль, на другом этапе развития – вопросам построения технологий, внедрению нового оборудования, изменению и налаживанию внутренних процессов. Именно поэтому на практике встречаются ситуации, когда многие управленческие процессы, включая процессы обработки документов, могут осуществляться «по старинке», практически вручную. Причин, почему так происходит, может быть несколько:
● отсутствие подготовленного персонала, менеджеров, которые смогут организовать и взять под контроль вопросы построения внутренних бизнес-процессов, добиться нужного результата;
● отсутствие знаний в этой области у руководства компании;
● отсутствие в компании средств, необходимых для оптимизации и автоматизации процессов;
● другие.
Ярким примером такой ситуации может явиться процесс согласования договорных документов. Когда организация небольшая или находится на начальной стадии своего развития, зачастую согласование документов (например, договоров) производится на бумажном носителе. В условиях небольшого документооборота и территориальной сгруппированности компании такой порядок работы с документами осуществляется быстро и не вызывает сложностей. Однако при росте компании, при появлении территориально удаленных подразделений - участников процесса согласования прежний процесс теряет свою эффективность, становится длительным, неудобным, не позволяющим быстро получить нужные результаты. Таким образом, возникает необходимость своевременного анализа внутренних процессов, разработки предложений по их изменению с учетом ресурсной составляющей, возможностей по автоматизации.
Затягивание вопроса оптимизации бизнес-процессов может привести к значительному замедлению развития компании, к отставанию от конкурентов, а в более сложных случаях - и к проблемам управленческого характера (непонимание процессов, происходящих в различных юридических лицах холдинга, невозможность оперативно получать необходимую информацию и принимать решения, потеря управляемости, появление различных рисков, включая финансовые и репутационные).
Отличительные особенности документопотоков холдинга
Некоторыми исследователями в области корпоративного управления отмечается, что управление холдингами наиболее часто строится по принципу «децентрализации операций при централизации контроля», что не может не сказаться на построении бизнес-процессов и документопотоков холдинга. Прежде всего, такой подход к управлению сказывается на корпоративном документопотоке, который осуществляется между юридическими лицами холдинга.
Рассматривая, как данный принцип реализуется на практике, можно отметить, что документы, включаемые в корпоративный документопоток, исходя из их содержания и предназначения (для кого, с какой целью разрабатывался документ), создаются на определенном уровне, в зависимости от функций и полномочий создавшего их органа или должностного лица. Таким образом, прослеживается прямая связь между организационной структурой, зоной ответственности руководителей, построением бизнес-процессов и организацией документопотоков.
Для наглядного примера приведем схему уровней создания распорядительных документов холдинговой компании (рис. 3).
Приказы директора управляющей компании могут содержать поручения для юридических дочерних обществ холдинга, регулировать деятельность функциональных направлений.
Текст такого приказа может выглядеть следующим образом:
1. Утвердить и ввести в действие форму финансового отчета предприятий холдинга (приложение № 1 к настоящему приказу).
2. Руководителям финансовых подразделений предприятий холдинга в срок до 01.03.2013 предоставить в Финансовый департамент Управляющей компании отчеты в соответствии с утвержденной формой. Ответственные: управляющие директора предприятий холдинга.
3. Контроль за исполнением настоящего приказа возложить на директора Финансового департамента Управляющей компании.
Таким образом, схема движения распорядительного документа управляющей компании холдинга будет выглядеть примерно так (рис. 4):
Из чего следует, что схема движения отчетных документов, созданных на уровне юридических лиц холдинга в соответствии с полученными поручениями, будет противоположной представленной выше схеме.
Это яркий пример организации одного из документопотоков холдинга. В холдингах есть и другие документопотоки, существующие в рамках реализации бизнес-процессов, в которых задействованы подразделения различных дочерних обществ, т. е. информация и документы могут создаваться в одном предприятии и в соответствии с требованиями процесса передаваться в другое. Важным моментом выполнения бизнес-процессов в холдинге является их подконтрольность головной компании холдинга.
Получается, можно говорить, что отличительной чертой организации документопотоков холдингов является движение документов в соответствии с существующими бизнес-процессами холдинга и в зависимости от сформированной матричной структуры. Именно поэтому при постановке задачи по выбору системы электронного документооборота для автоматизации процессов обработки документов холдинга необходимо понимать, что система должна позволять не только создавать, согласовывать, хранить документы, осуществлять контроль над их исполнением, но и обмениваться документами на корпоративном уровне: между управляющей компанией и дочерними обществами, между дочерними обществами холдинга.
Основные аспекты при выборе СЭД для холдинга
Если организационная структура холдинга приведена к единому стандарту, процессы написаны и выполняются оптимально, наступает следующий этап большого проекта - выбор СЭД.
На различных конференциях и форумах вы наверняка слышали, что почти все СЭД позиционируются их разработчиками как системы корпоративного уровня, т. е. подходящие для внедрения в крупных компаниях и холдингах. Так ли это на самом деле? Давайте разбираться.
Прежде чем выбирать СЭД для холдинга, необходимо четко определиться с программной платформой, на которой должна быть реализована СЭД, с областью автоматизации (какие бизнес-процессы планируется автоматизировать в первую очередь и в дальнейшем).
Программную платформу стоит выбирать исходя из того, на каких информационных системах в холдинге реализовано ведение кадрового учета и бухгалтерии, базируется почтовая система, т. к. приобретаемая СЭД должна условно легко интегрироваться в информационную среду холдинга, позволять строить «сквозные» процессы, иметь встроенный механизм управления доступом, опираясь на сложную структуру холдинга.
Если для бухгалтерского учета и управления кадрами используются решения, разработанные на единой платформе, это может облегчить задачу выбора СЭД, но вместе с тем ставит еще одну более серьезную задачу: оценить потенциал использования текущих информационных систем холдинга и принять решение либо о выборе СЭД на аналогичной программной платформе, либо о смене всего комплекса информационных систем и выбора новой, более мощной программной платформы. Такое решение может приниматься исключительно коллегиально с привлечением профильных специалистов каждой области, где используются информационные системы, а также с обязательным комплексным анализом со стороны ИТ-специалистов, отвечающих за архитектуру баз данных, за их развитие и поддержку. Именно таким образом принятое решение будет позволять четко строить планы по комплексной автоматизации простых и сложных процессов холдинга не только на ближайший год, но и на среднесрочную перспективу, в совокупности оценивать все положительные и слабые стороны любого выбираемого решения.
Не менее важной по значимости при выборе СЭД считается возможность программного продукта поддерживать сложную структуру холдинга, т. к. это является основой построения всех процессов обработки документов, настроек доступов.
Если рассматриваемая в качестве потенциального решения СЭД не позволяет строить многоуровневую структуру в линейном, в функциональном разрезе, то это значит, что она априори не подходит для автоматизации документооборота холдинга.
Есть еще один немаловажный аспект, на который также стоит обратить внимание при выборе системы для автоматизации документооборота: СЭД корпоративного уровня должна позволять работать с централизованными справочными базами данных, такими как «Справочник контрагентов», «Справочник видов документов» и пр. Такая возможность позволит унифицировать и стандартизировать ряд процессов холдинга, что в значительной степени будет способствовать повышению управляемости, эффективности контроля за осуществлением процессов.
Конечный выбор информационной системы для автоматизации документооборота необходимо проводить на основании детально разработанного технического задания, в котором четко прописаны не только область автоматизации, но и желательные технические характеристики выбираемого решения, требования к интерфейсной части.
Описанный подход к выбору СЭД для холдинговой компании позволит выбрать решение, которое даст холдингу возможность динамично развиваться, эффективно реализовывать все управленческие решения, детально строить стратегические планы.
Однако правильно проведенный процесс выбора СЭД еще не означает положительного результата при реализации проекта.
Подробнее о том, как проходит внедрение СЭД в холдингах, чем оно принципиально отличается от проектов в обычных компаниях, на что стоит обратить внимание, мы поговорим в следующей публикации.
Источник: Журнал "Современные технологии делопроизводства и документооборота"
Комментарии 10
Всё течет, всё меняется, и даже при качественном внедренни системы и хорошей формализации БП, настумает момент, когда нужно внести изменения в автоматизированные БП. Очень важно чтобы выбранная система имела открытый код и позволяла оформлять бизнес-процессы(БП) в электронном виде самостоятельно. Холдинговые структуры часто имеют свой большой штат ИТ-специалистов, которые могли бы сами модифицировать систему. При отсутствии гибкости и возможности самостоятельной модификации предприятие получает зависимость от разработчика(вендора), а соответственно несет большие затраты при каждом изменении в бизнес-процессах предприятия. С этой точки зрения достаточно привлекательна система Directum, разработчики которой не только дают возможность самостоятельно модифицировать систему, писать новые технические решения, но и обучает на своей базе специалистов Заказчика.
Вы имеете в виду код для БП? А в каких системах (из более-менее распространенных) это не так?
Что вы имеете ввиду?
Альвина, у меня создается ощущение, что на рынке создали миф и все его принимают как данность. Миф в том, что гибкость конструктора и возможность самому заказчику модифицировать систему это плюс.
Доработка и настройка ИТ-продуктов не является прямым бизнесом заказчика. Соответственно у него нет достаточной экспертизы в этой теме, создаваемые самостоятельно решения оказываются хуже, делаются дольше и выходят дороже!
А где здесь миф?
Да.
Да.
Да.
Только вот какая штука: на рынке кроме заказчика и вендора системы есть еще и другие стороны. Те же интеграторы, к примеру.
Возьмите в качестве примера ИТ-продукта 1С-Предприятие. Заказчик легко может найти себе исполнителя для настройки и доработки системы. Ему вовсе не надо обращаться напрямую к вендору. Неужели это не плюс?
Андрей, очень часто выбором какой-либо системы для предприятия занимаются ИТ-шники. Так вот гибкость настроек, мощный встроенный дизайнер бизнес-процессов и пр. отражают взгляды именно ИТ-специалиста. Он глубоко верит в то, что все эти "возможности" позволят ему сделать компанию счастливой. Так же он верит в то, что его отдел станет еще больше и значимей, т.к. чтобы не быть зависимым от вендора в его отделе будет куча специалистов, которые и будут настраивать и подгонять все эти гибкие системы.
А теперь попробуем посмотреть на эту тему глазами собственника бизнеса или высшего руководителя.
Во-первых, им не нужны "возможности", им нужен быстрый и качественный результат. Они не планируют осваивать новое направление деятельности компании под названием "внедрение и доработка ПО", они хотят получить ИТ-инструмент для поддержки бизнеса. Соответственно идеальным вариантом для них будут методически и технологически выверенные готовые решения, внедряемые экспертной компанией, которая научит тому как жить в новой реальности. Так же они не хотят потом постоянно вкладывать кучу денег в эксперименты своих "автоматизаторов" по развитию системы собственными силами.
Поэтому я считаю что все эти конструкторы - это вред для бизнеса! Настроек должно быть ровно столько сколько нужно для адаптации решения к конкретному предприятию. Внедрять решения должна экспертная компания, которая лучше заказчика знает как ему нужно автоматизировать документооборот.
Александр, вы уже не первый раз говорите только о крайних случаях. Я же вам привел пример с интеграторами: далеко не каждую систему систему внедряет и настраивает под заказчика сам вендор. И грамотный заказчик выбирает конструктор не потому, что сам может туда залезть, а потому что ему интегратор может гарантировано "допилить" систему до нужного состояния.
Фраза "Настроек должно быть ровно столько сколько нужно для адаптации решения к конкретному предприятию" - просто софистика. Вендор никогда не знает сколько нужно настроек для адаптации к конкретному предприятию. Узнает только когда поработает с ним. Точнее, даже так: если поработает с ним.
Андрей, я прекрасно понимаю Вашу позицию, попробую уточнить свою чтобы была понятней мысль которую я хочу донести.
Гибкие конструкторы не отрицаются мною в принципе, но практика показывает что в очень многих случаях для бизнеса это вред. В сознании внедряющих знания и практики начинают подменяться на потенциальные возможности. "...Ведь мы же всегда можем быстро все донастроить, поле прикрутить, процесс доработать...". И это все на фоне практически полного отсутствия опыта автоматизации у самого заказчика и слабости многих подрядчиков, которые используют принцип "как скажете, так и сделаем, система гибкая, настроить можно что угодно". В итоге думаю Вам известно сколько на рынке плохих проектов - в пресс-релизах все хорошо, все оптимизировано и ускорено... а приходишь к этому заказчику, там закуплено 300 лицензий, а используется только 20, при этом из всех процессов используется только регистрация входящей и исходящей документации. И получается что на такой незначительный результат потрачено очень много денег собственников бизнеса.
Для типовых делопроизводственных процессов, процессов согласования и рассмотрения документов, процессов контроля и исполнения поручений можно создать готовые решения, которые "прикручиваются" только минимальными настройками и они будут работать, а запускаются в течение 1-2 месяцев даже в крупных компаниях. И этим путем сейчас стараются идти многие вендоры.
Вот для специфичных процессов документооборота компании нужен конструктор и мощный workflow, но таких проектов не более 5% у любого вендора СЭД/ECM.
В итоге получается что при выборе СЭД/ECM возможности гибкой настройки являются чуть ли не ключевым критерием, вендоры на их разработку тратят очень много сил, а реально нужны они столь малому количеству заказчиков.
Не софистика, а опыт :)
Кстати, интересный факт. Я за 10 лет работы в отрасли постепенно приходил к выводу что уникальность каждого заказчика (я сейчас говорю о типовых процессах ОРД, приведенных мной выше) совершенно надумана. Вся уникальность чаще всего проявляется просто в привычке, например, в наименованиях полей. И пару лет назад я решил что можно выпустить готовые решения, которые будут одинаковы для всех заказчиков независимо от размера и отрасли.
Конечно были опасения, что такой подход не сработает. Даже многие мои коллеги в него мало верили. В результате сработало!
Конечно дается это нелегко в начале проекта, заказчик привык к другой модели и постоянно хочет заниматься творчеством :) Но если аккуратно занимать твердую позицию, то заказчик постепенно сдается под натиском результатов, причем в первую очередь это начинает понимать высшее руководство, а оно уже начинает осаждать особо прытких деятелей внутри компании, которые полагают, что своими идеями "в тыщу" раз улучшат решение.
Александр, я тоже имею не малый опыт, и согласна, что очень часто клиент сам себе надумывает особенности своих БП, и часто можно внедрить просто типовую "коробку" и прогнуть существующие процессы под систему и пользы от этого тоже иногда больше. Но есть и такие случаи, когда компания имеет большой ITштат талантливых программистов, которые некоторые вещи вполне могут сделать сами, например сделать новый отчет для делопроизводителя или удобную кнопочку на форме, которая облегчит, кому-то жизнь. И обращаться по таким пустякам каждый раз к разработчику и переписываться месяцами смысла нет, хотя иногда это полезно))) потребность в кнопочке может сама собой отвалиться))) за это время...
Да, были примеры, когда доработки процессов приводили к абсурду, тк заказчик не всегда понимает, что такое ХОРОШО, а ЧТО такое плохо, но при надлежащем взаиможействии и поддерже проекта со стороны исполнителя - это большая редкость.....
Так что возможность написать в системе свой отчет или внести в него изменение, возможность создания собственных мастеров или шаблонов (как например в системе Directum), очень полезная штука и клиент готов за эту возможность платить.
И кстати наличие открытого кода дает возможность интеграторам дорабатывать систему для клиента, и такие варианты предпочтительнее, чем вариант , когда только разработчик самой системы может настроить её под особенности предприятия. Это увеличивает оперативность внедрения и качество обслуживания, хотя всё индивидуально и не будем впадать в писсемизм))) интеграторы, тоже бывают разные.
прстите пессимизм)))