Доля электронного документооборота в России относительно невелика. Это связано, в первую очередь, с традициями и определенным консерватизмом, а также непростым техническим и финансовым состоянием многих предприятий. Однако потребность отечественных предприятий в совершенствовании документооборота очень высока. В связи с этим рынок СЭД достаточно быстро растет, и уже есть, пусть и немногочисленные, глобальные внедрения СЭД. Проектов, ставящих явную цель реализовать в документообороте принципы процессного управления, также немного. Поэтому каждый из них заслуживает внимания.
Опыт ОМК, где компанией iDoc недавно была внедрена система управления документами и бизнес-процессами DocsVision, в этом смысле достаточно полезен.
О том, как проходило внедрение СЭД, корреспондент CNews спросил участников проекта. На вопросы ответили Сергей Пухов, руководитель аппарата президента Объединенной металлургической компании, и Александр Сидоренков, генеральный директор iDoc.
Сергей Пухов: Решение принималось на этапе принятых принципиальных решений о модели управления и организационной структуре на среднесрочную перспективу: на такой фазе развития компании автоматизация процессов и документооборота и наиболее реализуема, и приносит наибольшие выгоды, поддерживая освоение и наполнение новой модели.
Структура управления ОМК
К моменту, о котором идет речь – середина 2005 г. - учет хозяйственной деятельности на крупнейших предприятиях группы ОМК был по основным участкам учета автоматизирован в ERP Oracle, был начат и шел проект по автоматизации бюджетного планирования и анализа в Oracle FA (OFA). Автоматизация административно-распорядительной деятельности и переписки была вполне логичным дополнением для того, чтобы были комплексно реализованы основные составляющие информационной архитектуры.
Если говорить о "единой системе управления документооборотом и бизнес-процессами", то я здесь в самом вопросе вижу некоторое преувеличение. Сегодня понятно, что "полная" автоматизация крупного предприятия, ведущего разноплановую деятельность, в системе на базе одного программного продукта вряд ли достижима, и мало кто ставит такую цель.
Архитектурное решение для крупной компании – это интеграция нескольких систем, отвечающих за свои функциональные контуры – ERP, MES, CRM, капитальные проекты, другие известные функциональные классы. Плюс интеграционная инфраструктура вокруг этого – управление НСИ, порталы, документооборот.
Хочу уточнить, что задача "единой системы" как базовой для административного документооборота всех предприятий, действительно, ставилась. А в смысле "единственной системы для автоматизации всех процессов" - разумеется, нет.
Возвращаясь к задачам и предпосылкам создания СЭД. Замысел был следующий. Во-первых, автоматизировать делопроизводство, как оно традиционно понимается – административно-распорядительный документооборот, систематизированный каталог нормативно-методической документации, переписка. Затем перейти к тому, чтобы выявлять присутствующие в переписке "процессы": здесь уже речь идет не об установленных в делопроизводстве "видах документов" как образцов оформления, а о типизации документов по содержанию и назначению в процессах, алгоритмизации их обработки и передачи, работе с содержательной структурой документов.
При этом изначально предполагалась такая установка, что процессы мы видим в пространстве всех систем, которые развиваем в архитектуре нашей "КИС", и автоматизируем в контуре тех систем, для которых эти процессы являются "основным профессиональным назначением". Хозяйственные, имущественные транзакции - в ERP, обмен документами при формировании бюджетов – в OFA. Распорядительные документы, коллегиальные формы работы – в СЭД, а кроме них, СЭД выступает подборщиком "прочих", "мелких", "нетипичных" процессов – что следует из гибкости средств СЭД и того, что в виде переписки эти процессы в СЭД и осуществляются изначально, в неструктурированном пока виде. В этом состоит инфраструктурная роль СЭД, несмотря на название "подборщик" - эта интеграционная роль в информационной архитектуре КИС очень значительная. Обычно такую роль "по остаточному принципу" играет электронная почта, но лучше переводить этот оборот в СЭД, где можно работать с внутренней структурой документов, типизировать содержание, агрегировать данные из документов для анализа.
Кроме того, являясь крупной компанией и работая для крупных компаний, ОМК сертифицирована и внедряет все новые международные стандарты, а они в отличие от "делопроизводства" имеют процессную основу. Поэтому задача была – реализовать управленческий документооборот в одной среде, как распорядительного, так и процессного характера. ОМК нацелена на результативность в методах управленческой деятельности. Уже до внедрения СЭД эти методы были развиты, благодаря вниманию руководства к этой теме и работе HR, а информация для этого поступает в значительной части из распорядительного оборота, из КИД. Эту сторону хотели усилить, погрузить в одну среду автоматизации.
Почему была выбрана именно DocsVision? Ведь на рынке много достойных систем.
Сергей Пухов: Как основная идея, мы хотели получить готовое прикладное решение в части делопроизводства, чтобы не заниматься разработкой этой вполне известной и традиционной функциональной части на "платформе-конструктуре". Но иметь при этом современную платформенную основу – с процессной архитектурой, работой по событиям, с масштабируемостью. Сегодня такие решения можно найти не только среди самых дорогих систем, средний класс систем очень укрепился. К моменту выбора мы уже развивали портал на Windows Sharepoint Services, имелось соображение для СЭД использовать что-то технологически близкое, мы изначально предполагали комплексировать СЭД с порталом в одну систему. Посмотрели несколько решений, предлагавшихся в этой категории, DocsVision в наибольшей степени отвечал и этим запросам, и критерию цены/качества.
В определенный момент нам потребовалось для иллюстрации целей проекта показать руководству, "как это будет в экранах", и мы в порядке ознакомления с системой сделали макет – наполнили справочники, несколько форм, имитировали небольшие процессы. Увидели, что систему можно "взять и начать с ней работать", это нас убедило.
Структура системы DocsVision в ОМК
Судя по задачам, проект задумывался не только как сложный, но и по масштабу очень большой: 3000 мест, на которые надо было развернуть систему, расположены в разных городах на разных предприятиях. И на каждом из них есть своя специфика… не пугали ли вас масштабы проекта?
Александр Сидоренков: Нет, масштабы нас не пугали. И не только потому, что мы имеем опыт работы с крупными компаниями. Трудность масштабирования проекта при внедрении часто связана с отсутствием отработанной и формализованной методологии, когда все люди являются уникальными и незаменимыми. Наши консультанты и инженеры тоже уникальны, но по своей компетенции, а не по ролям в методологии. И методология у нас своя, четко прописана. Именно такая детальность позволяет нам быстро масштабировать ресурсы, вводить в проект новых исполнителей, обеспечивая заданное качество на выходе.
Сергей Пухов: Масштаб – это показатель системы, который всегда должен если не "пугать", то требовать самого пристального внимания, просто из инженерных соображений. Функциональные недостатки обычно можно закрыть какими-то "заплатами", но если программная система не масштабируется… поспрашивайте тех, кто занимался "растягиванием" обычных для недавнего времени двухзвенных клиент-серверных систем на масштаб более 400-500 мест, впечатления будут убедительные.
Строго говоря, гарантией здесь может быть только неоднократно опробованное использование системы на том масштабе, который вы планируете. В нашем случае, можно было только косвенно убедиться – посмотреть работу "клиента" на тонких и неустойчивых каналах, посмотреть архитектуру, характер зависимости от роста объемов, нагрузок. Сейчас, при расширении зоны охвата системы, мы тревожных признаков по этой части не видим. Но мы и от конечного целевого масштаба системы пока еще далеки, сейчас как раз идет освоение и распространение системы на структуру компании.
Что касается функциональной масштабируемости, то есть добавления прикладных особенностей, которые обнаруживаются при распространении системы на новые площадки, DocsVision подтвердил высокую гибкость, средства настройки и программирования в нем весьма многообразные. Функциональные дополнения по "частным техническим заданиям" мы просим у iDoc довольно часто, система и настройщики с ними справляются.
Кстати о партнере: мы выбирали внедренца с пониманием того, что не готовы детально сформулировать ТЗ. Мы видели критерии системы, "облик" управленческой работы в системе, но не детальную функциональность "в виде экранов". Поэтому искали компанию, которая была бы готова работать в темпе методических разработок, понимала бы значение проработки деталей.
В этом смысле мы остались довольны - уровень понимания партнером предметной области позволил общаться на одном языке, плюс их знание системы и умение настраивать под новые требования дали нам то, что свойственных для подобных проектов периодов "ожидания, когда разработчик найдет прикладное решение", практически не было. Можно сказать, что критический путь проекта прошел по методическим работам заказчика. Оценку iDoc по "общим местам" - технической подготовке, проектному управлению и т.п., я был тоже дал вполне высокую.
Расскажите, с какими трудностями вы столкнулись, внедряя СЭД на таком большом предприятии?
Александр Сидоренков: Проекты такого масштаба легкими не бывают. Наверное, одна из главных трудностей – необходимость реализации совмещений разных людей в управлении предприятиями холдинга. В таких случаях человек как бы является пользователем дважды, при этом с разными правами на разных предприятиях. Ну и заместительство – тоже вещь непростая, особенно, когда у руководителя несколько замов, каждый со своей зоной ответственности. Для реализации таких схем потребовалось задействовать механизмы процессного управления.
Как повлиял этот проект на вашу компанию, появились ли новые компетенции, типовые решения, модели управления проектом?
Александр Сидоренков: Конечно, мы приобрели дополнительный, во многом новый опыт, новую компетенцию. Например, решение, разработанное для карточки протокола совещания, мы собираемся сделать типовым модулем расширения СЭД.
Можно сказать в целом, что мы стали сильнее как специалисты по ИТ-консалтингу в области автоматизации документооборота. Это вполне соответствует нашей специализации.
Пришлось ли обращаться к поддержке разработчика? Просить его что-то исправить, улучшить, доработать?
Александр Сидоренков: Естественно, мы достаточно тесно общаемся с разработчиком платформы. Именно подобное взаимодействие и позволяет в итоге предлагать нашим клиентам решение, наиболее полно реализующее именно их требования и задачи. Мы очень довольны поддержкой разработчика, оперативностью их отклика и динамикой расширения функционала системы.
Владимир Андреев: Дополню Александра. В этом году мы, наконец, придали официальную форму нашей поддержке партнеров в конкретных проектах: создали консалтинговое бизнес-направление. Главная задача этого подразделения – как раз помощь партнерам вплоть до прямого участия в их проектах в качестве субподрядчика. Это должно не только помочь партнерам, но и повысить качество услуг, получаемых заказчиками.
Должен также сказать, что помощь нашим партнерам способствует развитию системы в правильном направлении. Ведь несложно придумать множество новых, интересных и изящных функций, гораздо сложнее понять, какие из них востребованы уже сегодня и каким клиентам они нужны. За прошлый год нашими партнерами реализовано около сотни проектов у разных заказчиков. Существенная часть этих проектов нам хорошо известна именно потому, что мы отвечали на вопросы, консультировали их по продукту и методологии внедрения, а иногда и делали доработки по их заказу. Надо только подчеркнуть, что доработки мы делаем только включаемые в стандартный продукт. То есть, никаких специальных версий у конкретных заказчиков не появляется. Иначе невозможно гарантировать миграцию системы заказчика на новую версию платформы.
Василий Полевой / CNews
