СЭД: путь от простого к сложному
Сегодняшней публикацией мы открываем серию материалов, позволяющих по-новому взглянуть на применение СЭД для автоматизации корпоративных бизнес-процессов. Реализация ВРМ-стратегии при помощи системы электронного документооборота может казаться заманчивой идеей — в конце концов, в любое современное решение встроен BPM-движок. Однако, взаимосвязь бизнес-процесса и документа на практике оказывается сложнее, чем представляется в теории. В серии статей мы совместно с экспертом Станиславом Макаровым расскажем о том, почему налаженная автоматизация хранения и обработки документов — первый шаг к будущей BPM-автоматизации. В последующих статьях мы планируем продемонстрировать актуальность этой мысли примерами реальных бизнес-процессов, таких как бюджетирование, договорная работа или материально-техническое обеспечение.
Возможности СЭД/ECM-систем за минувшие двадцать лет –, а именно таков возраст этого рынка — значительно выросли. Им под силу любые задачи по автоматизации бизнес-процессов, сильно завязанных на работу с документами. Сразу оговоримся: здесь нет противостояния с BPM как с методологией. Внутри СЭД/ECM-решений как правило интегрированы современные BPM-движки, а уж их правильное использование — на совести заказчиков и внедренцев. Современная СЭД — это конструктор бизнес-объектов и, в общем-то, автоматизация документооборота с помощью подобных систем есть частный случай. Таким системам можно доверить очень широкий класс задач по управлению информацией на предприятии. (Примечание: здесь и далее, как разработчики СЭД ТЕЗИС, мы опираемся в первую очередь на возможности своей системы)
Итак, получив в руки мощный универсальный инструмент, вам хочется сразу, одним махом, решить все наболевшие вопросы. Подумаешь, документооборот, входящие-исходящие! Это же вчерашний день! Давайте сразу автоматизировать самые сложные наши процессы! — Для кого-то это договорная работа, для других бюджетирование, для третьих — материально-техническое снабжение. Сразу и не угадаешь, что наиболее важно — внутри большой организации все эти решения могут быть одинаково востребованы. И хуже того — все взаимосвязаны. Вот тут нас и подстерегает ловушка: автоматизация одного участка не обязательно даст прирост производительности по организации в целом. Потому что ни одно подразделение не работает изолированно от других, потери производительности на стыках могут свести на нет эффект от внедрения.
Ловушка парадокса продуктивности
В более широком контексте это явление известно как «парадокс продуктивности», сформулированный нобелевским лауреатом Робертом Солоу, который гласит, что «вы можете увидеть эру компьютеров повсюду вокруг себя, но не в цифрах роста производительности» (Solow, 1987), и заключается в несоответствии затрат на ИТ полученным результатам. Статистические данные многократно подтвердили, что рост продуктивности не коррелирует с затратами на ИТ — чем больше страны инвестируют в информатизацию, тем больше у них расходы на создание и поддержание самих ИТ-систем, при этом общий выигрыш в производительности оказывается не так уж велик.
Однако, не все так печально, надежда есть! Новейшие исследования показали, что на уровне стран получается преодолеть эту неприятную тенденцию, когда достигается некоторый критический объем вложений в ИТ-инфраструктуру — то есть, когда все предприятия и организации начинают взаимодействовать друг с другом в электронной форме, бизнес-процессы выходят на новый уровень эффективности.
Строго говоря, с научной позиции парадокс Солоу проявляется на национальном и глобальном уровнях, а не на уровне отдельного предприятия, которое может инвестировать в ИТ с гораздо большей отдачей, чем в среднем по отрасли или стране. Тем не менее, некоторые аналогии прослеживаются — как мы знаем, «островковая» автоматизация большого эффекта не дает.
«Две копейки» от СЭД — в общее дело
Позвольте СЭД вставить здесь свои две копейки: вы не сможете выстроить сквозные, кросс-функциональные бизнес-процессы в организации и оптимизировать общение с внешним миром — с клиентами, поставщиками и партнерами, пока вы не создадите единое информационное пространство и общий репозиторий документов. СЭД — это важная часть ИТ-инфраструктуры. Пусть не самая дорогая и не самая сложная — по сравнению с внедрением ESB (Enterprise Service Bus) или с тяжелым ERP-проектом. Но без единой базы документов, хранящейся в СЭД, многие другие инициативы просто буксуют.
Буксуют они потому, что бумажный документ или даже файл, если он не зарегистрирован в системе, становится «узким местом» в бизнес-процессе, вызывает затраты времени на прикрепление, копирование, пересылку, часто теряется, приходит не в том формате, и т.д. и т.п. В общем, если нет культуры и политики работы с документами, то с ростом информатизации бардак будет только усиливаться.
Итак, правильнее всего рассматривать СЭД не просто как очередную прикладную систему, а как обязательный элемент ИТ-инфраструктуры, и соответственным образом к относиться к ее внедрению:
- Планировать, что со временем доступ к системе понадобится всем сотрудникам организации, а не какой-то узкой группе «делопроизводителей»;
- Заранее подумать об интеграции СЭД с ERP и другими вашими бизнес-приложениями — потому что все равно обязательно понадобится;
- Начать с простых проектов, и не торопиться с выводами, понимая, что полная эффективность придет потом, когда СЭД «накроет» всю организацию.
Практика показывает — подход постепенного усложнения работает
Обзор крупных внедрений СЭД ТЕЗИС подтверждает практическую полезность данного подхода — условно назовем его «начни с СЭД, сложные процессы потом». Например, компании «Русская платина» нужно было автоматизировать работу с договорами. Но прежде, чем погружаться в специфику договорной работы в организации, нужно было обеспечить инфраструктуру документооборота. «Русская платина» живет в распределенном режиме — головной офис в Москве, а производственные подразделения в Хабаровске. Поэтому сначала пришлось разработать и внедрить решение по синхронизации двух площадок, чтобы реализовать «смежные процессы» — когда участники цепочки согласования находятся кто в Москве, а кто в Хабаровске, но при этом работают как будто в одной системе, хотя их на самом деле две — потому что централизованное решение слишком бы зависело от канала связи и был бы высок риск простоя.
В НК «Альянс» тоже начинали внедрение СЭД, имея целью сократить сроки согласования и минимизировать риски потери документов — вполне обычное желание любого заказчика. Поскольку бизнес-пользователи не хотели «прогибаться» и подгонять свои процессы под то, как это реализовано в системе, критерием выбора была гибкость и возможность настройки процессов.
(Небольшая ремарка: Бизнес-консультанты могут раскритиковать такой подход. По науке, нужно провести реинжиниринг и оптимизацию бизнес-процессов. Никто не спорит, так оно и есть — только это будет не ИТ, а консалтинговый проект. Выбранная ранее гибкая система может быть перенастроена на новые процессы, в соответствии с рекомендациями консультантов — здесь нет конфликта. Но если «захардкодить» систему управления под старые процессы, то потом ее придется просто выкинуть.)
На первом этапе особенно остро стоял вопрос ускорения процесса согласования договоров и это удалось решить с помощью СЭД. Дальше — больше: ведь суть договорной работы состоит не в формальном визировании документов или в вылавливании юридических нюансов. Задача согласующего на самом деле состоит в том, чтобы принять решение, нужен ли вообще этот договор, можно ли заключить его сейчас или надо подождать, подходит ли нам этот контрагент или нет. То есть, управление договорами — это часть управленческого учета, что влечет за собой соответствующий блок функциональных требований. В итоге получилось, что решение выросло потом в сложную казначейскую систему, которая позволяет работать с платежными документами к договорам, вести финансовое планирование, проверять заявки на соответствие бюджету и прочее. Это еще СЭД или уже нет? Пусть ломают головы теоретики. А для заказчика это система, которая решает его проблемы :)
Подходит ли вам «коробка»?
На этот вопрос с уверенностью можно ответить: «Да!» На первых порах СЭД из коробки (с необходимыми при внедрении настройками, но без глубокой кастомизации) прекрасно справится с большим объемом типовых задач в любой организации. Потому что работа с организационно-распорядительными документами в принципе везде устроена одинаково. Специфика начинается, когда вы вторгаетесь в какие-то бизнес-процессы, хотя бы в договорную деятельность. Хотя Гражданский Кодекс у нас для всех одинаков, организации работают с договорами по-разному — потому что управленческий учет есть процесс весьма творческий. Следом за договорами у вас могут появиться и более широкие пожелания — как это было у НК «Альянс» и других клиентов Haulmont.
Надо ли сразу ставить задачу на доработку системы, если все организации уникальны? Не факт. Не научившись пользоваться штатными возможностями СЭД, вы можете так ее «закастомизировать» своими требованиями, что потом поддержка будет обходится очень дорого (снова вспоминаем про парадокс Солоу). Начините с использования стандартных функций, пусть люди привыкнут работать с электронными документами. Параллельно можно вести обследование и проектирование новых бизнес-процессов и доработку системы.
Методология Agile, широко распространенная в разработке ПО, вполне применима и к бизнесу: наращивайте функциональность постепенно, шаг за шагом. Планируйте улучшение и развитие системы — цикл PDCA (Plan-Do-Check-Act) вам в помощь! И вы не заметите, как из стандартной СЭД у вас получится система, точно настроенная на потребности вашего бизнеса.
