Восемь ошибок при внедрении документооборота
Каждая компания с развитием бизнеса и ростом потоков бумажных документов сталкивается с необходимостью автоматизации документооборота. К сожалению, нередки ситуации, когда компании не осознают всей важности этого события, полагая, что по сравнению, скажем, с внедрением масштабной ERP-системы автоматизация документооборота – это процесс быстрый и простой. Внедрение СЭД обычно не сопровождается «шоу по всей программе», когда в проект вовлекается огромное количество людей, обязанных помочь. Обусловлено это тем, что ERP – это как центральная нервная система организма – система, связанная со всеми ключевыми процессами жизнедеятельности компании. Принято считать, что с СЭД все значительно проще: обычно эта система нужна для обеспечения работы только юридического отдела, иногда также может использоваться бухгалтерами и финансистами. Таким образом, Заказчик иной раз может демонстрировать несерьезный подход к внедрению СЭД, который, в свою очередь, может создать проблемы на пути к успешной реализации проекта и достижения запланированных показателей эффективности. Давайте разберем, какие именно ошибки, а, следовательно, проблемы наиболее часто встречаются в рамках проектов по внедрению СЭД.
«Бесцельное» внедрение
Распространенная проблема, с которой часто начинаются многие другие сложности, связана с тем, что заказчик неверно определяет цели проекта. Заказывая внедрение СЭД, можно услышать что-то вроде «нам ничего особенного, просто документы согласовывать»… Такой подход всегда ошибочен, целью внедрения должен быть именно результат, будь это систематизация процессов, уменьшение времени согласования, прозрачность процедуры согласования или получение в конечном итоге единого архива согласованных документов. При этом автоматизация документооборота может на выходе не ограничиваться согласованием документов. От системы требуют удобного интерфейса, напоминания о предстоящих действиях, формирование отчетности, интеграции с ключевыми системами предприятия по основным справочникам (контрагенты, доверенности, аналитики, организационная структура и т.д.), эти важнейшие функции почему-то принято забывать и не учитывать, а, следовательно, неправильно формулировать цели. В итоге на запрос «просто согласовывать документы» может получиться соответственный результат: отдельная система, оторванная от процессов предприятия, совершенно не соответствующая ожиданиям заказчика.
Итак, прежде всего необходимо правильно и детально обозначить цели внедрения, учесть все особенности бизнес-процессов и организационной структуры предприятия, вспомнить, какие отчёты обычно требуются руководителю компании или аудиторам, проанализировать какая информация (справочники) уже встречаются в других системах компании (для проектирования возможной интеграции). Задачу формирования целей также можно поручить интегратору, но важно и нужно это сделать до начала внедрения системы. Увы, интегратор - не волшебник, и не умеет сканировать текущие бизнес-процессы компании, а также мысли по их изменению (хотя, конечно же, очень хочет). А потому велик риск, что при некорректной формулировке целей вам подберут неправильное решение, которое может стоить либо неоправданно дорого, либо слишком дешево, поскольку не будет содержать жизненно необходимой функциональности, наличие которой может представляться Заказчику как само собой разумеющееся. Будьте честны перед собой и интегратором как перед врачом, и тогда получите правильное «лечение».
Отсутствие регламента
Допустим, мы определились с четкими целями, благополучно избежав первой проблемы. Далее по курсу – еще один момент: с началом внедрения системы в компании начинают активно перекраивать внутренние процессы. Обычно ситуация заключается в том, что давным-давно, никто не помнит когда, в компании был создан регламент согласования документов, и с тех пор процессы устарели и их изменение нигде не фиксировалось. И вот настает момент, когда руководство принимает решение о необходимости автоматизации бизнес-процесса - в нашем случае, документооборота - и в предвкушении потирает руки: мол, сейчас мы заодно и применим все, что вычитали в интернете, используем инновационный подход, создадим целую философию! На волне такого энтузиазма перекраивание процессов начинается параллельно с внедрением системы, поскольку Заказчик уверен, что система решит все его проблемы.
Никакая система не решит проблем, если эти проблемы связаны с неактуальными бизнес-процессами. Их решает правильный подход, который заключается в анализе текущих бизнес-процессов, их реорганизация, формирование внутренних регламентов, а затем контроль исполнения. Система – это всего лишь инструмент, который в зависимости от избранного подхода может быть, как и крайне эффективным, так и абсолютно бесполезным средством. Если отдел вашей компании согласовывал документ десять дней – от одного лишь факта внедрения системы эта цифра вряд ли уменьшиться. Если в регламенте не прописаны сроки согласования документов, и кто их контролирует (возможно, даже с применением штрафов), система, позволяющая осуществлять согласование быстрее, не изменит ситуацию. Да, с помощью системы проще отследить факт просрочки согласования документов, завалить напоминаниями согласующее лицо, эскалировать задачу на руководителя, но не более. Поэтому очень важно изначально, поставив цели внедрения, описать процессы документооборота во внутреннем регламенте, и только после этого приступить к автоматизации. Никак не наоборот! Не забыв при этом указать, кто будет отлеживать ключевые параметры, которые больше всего волнуют сотрудников, руководителей компании (сроки, корректность введённых данных, маршруты и т.д.).
Реализация проекта без участия конечных пользователей
Если у вас есть регламент, он должен быть донесен до всех, кто будет работать с системой до старта работы в ней. Бывают ситуации, когда собираются генеральный директор, топ-менеджеры, юристы и «соображают на троих». Согласно принятому решению, внедряют систему, с которой также необходимо работать и другим сотрудникам – например, менеджерам, секретарям. Понятно, что здесь дело нередко может обернуться возмущением со стороны последних: «неудобно, где мне ввести ключевые параметры, которые я использую для последующего анализа»… Основываясь на нашей практике, отмечу, что такие проекты плохо заканчиваются: если в формировании системы не участвуют ключевые пользователи, в итоге они либо работают крайне неэффективно, либо и вовсе бойкотируют новое внедрение. Таким образом, и консалтинговой компании, и заказчику нужно понимать, что при внедрении системы нужно обязательно учитывать все звенья цепочки: секретарей, принимающих документацию, менеджеров, инициирующих процессы согласования, юристов, бухгалтерию и т.д. – представители всех видов пользователей (инициаторы, согласующие, контролёры и т.д.), так или иначе участвующие в процессе, должны встретиться с представителями консалтинговой компании для интервью. В нашей практике был пример проекта: ключевой задачей было автоматизировать прием входящих документов для секретарей для их последующей регистрации в системе и запуска далее по маршруту к конечным получателям. Регламента не было, процесс «дорабатывали» на ходу. До секретарей нас не допустили – мол, зачем, мы сами все им потом расскажем, а не согласятся – уволим и наберем новых. В итоге после внедрения секретари начали выражать крайнее недовольство, т.к. часть их функций была забыта… и увольняться сами. Процесс в итоге пришлось срочно дорабатывать.
Одна голова – хорошо, а две лучше?
Крайне важно, чтобы среди всего большого количества людей, задействованных в реализации проекта, выделили одного ответственного, принимающего итоговое решение. Не десятерых, не четырех, даже не двоих - только одного. Несколько человек, возможны только в случае, если они отвечают за совершенно разные бизнес- процессы. Возникают ситуации, когда представители заказчика радостно заявляют: «Мы же дружная компания, большая семья, давайте принимать решение все вместе!». Знайте, что с таким подходом вы будете как никогда близки к провалу. «Дружная компания» на интервью превращается в настоящий базар и вечер воспоминаний, потенциальная система обрастает пятьюстами функций, часть из которых логически противоречит друг другу, а часть и вовсе не потребуется на практике… Во избежание всего этого запомните: последнее слово должно быть только за ОДНИМ человеком.
Разумеется, он может со всеми посоветоваться, провести совещания, устроить голосование – но при этом обязан иметь собственную четкую позицию. Иначе такой проект не сулит ничего хорошего. Мы сталкивались с ситуацией, когда сотрудники разных отделов компании-заказчика до внедрения системы делали десять разных отчетов в Excel. Все привыкли делать по-своему – следовательно, была поставлена задача по автоматизации всех десяти видов отчетов с одинаковыми данными. Проблема возникла, когда нужно было предоставить руководству один, общий отчет – а тут целых десять, и какой же нести руководству?
Основываясь на нашем опыте могу сказать, что рабочая группа, участвующая в формировании требований к функциональности (согласующие техническое задание (далее ТЗ) и тестирующая решение, также должна содержать ограниченное количество участников– иначе такая работа имеет все шансы, опять-таки, превратиться в один большой митинг и затянуть сроки внедрения.
Чукча – не читатель
Еще одна проблема связана с тем, что люди не хотят читать документы по описанию функциональности, которую интегратор предлагает внедрить. Типичная ситуация: составили документ и отправили всем на согласование. Все, естественно, жутко заняты, мол, «чтением заниматься некогда, мы как-нибудь потом». Чуть позже наступает час «Ч» и приходит время подписания протоколов. Подписанты читают станицы по диагонали, ведь мы уже всё сказали на интервью, и все подписывают, «чтобы уже наконец отстали». На основе подписанных протоколов системный интегратор пишет объемное 100-страничное ТЗ со всеми деталями, и карусель по сбору подписей представителей Заказчика запускается по новому кругу. И вновь повторяется та же история – ТЗ утверждается, практически не глядя. На основе подписанного ТЗ конструируется система… и начинается веселье:
- Что это еще за система? Нам все нужно совсем по-другому.
- Как это по-другому? Вы же подписали ТЗ, там все это было прописано.
- Ну да, подписали, но помните, мы же вам говорили…, и мы надеялись, что вы сделаете как надо, а не как у вас тут написано.
Нужно понимать, что ТЗ не только для интегратора, оно в первую очередь для заказчика. Потому что система на основании ТЗ не «наша», а «ваша». «Ваша», т.е. заказчика, и ТЗ – «ваше» для заказчика, чтобы не упустить детали и особенности бизнес-процессов. Именно для этого создаются ТЗ и другие документы, предоставляемые компанией-исполнителем, с которыми заказчик должен, специально выделив для этого время, очень внимательно ознакомиться во избежание споров на тему «говорили-не говорили». Не стоит тут так же находить «отговорку», я бы, конечно, почитал, но там одни технические термины, я ничего не понимаю, вот сделают – потом посмотрим. Не понимаете – просите интегратора объяснить, составить словарь терминов, поделить ТЗ на две части: бизнес-процессы и технические параметры, т.к. это ваша будущая система и вы в ней должны ориентироваться. На этой почве у нас появилась интересная практика – «совместные чтения»: мы специально встречаемся с клиентом и вместе читаем ТЗ. В зависимости от случая и уровня вдохновения иногда даже рисуем – все для того, чтобы заказчик воспринял всю информацию, прописанную в документе.
We don’t need no motivation
У сотрудников обязательно должна быть мотивация качественного и своевременного закрытия проекта. Это может быть премия, путевка, отпуск, лишний выходной, шоколадная медаль – все, что угодно. К сожалению, нередки случаи, когда пользователь может затягивать согласование, тестирование, подготовку начальных данных или выполнение еще какой-либо многоэтапной операции по проекту, поскольку к этим задачам не привязано никаких KPI, бонусов и т.д. Ведь для сотрудников такой проект – это нагрузка к уже имеющимся задачам. Тут может возникнуть мысль: «зачем мне лишняя головная боль - лучше я буду чинить всяческие препятствия на пути к внедрению: говорить, что мне неудобно работать с системой, функциональность не логична, а интерфейс из 90-х…все, не хочу, не буду!»… В итоге – впустую потраченные немалые деньги на внедрение системы и неудачный, бессмысленный проект на выходе.
Оптимальным решением в данном случае будет прописать матрицу сфер ответственности по проекту, кто за что отвечает, и кто и что за это получает. Иначе здесь может возникнуть еще одна проблема: допустим, возникают трудности интеграции нового решения с какой-нибудь системой - два дня исполнители бегают по офису с вопросом: «где ответственный?» А Бог его знает, кому это надо. Вот и получается, что вроде бы и никому – у всех и так есть, чем заняться в рабочее время. Процесс встает и на выходе получаем ту же картину – затянутые сроки и недовольный клиент.
Повторюсь, несмотря на то, что к СЭД не принято относиться с таким же трепетом, как, например, к ERP, это все равно важная система, использование которой нужно мотивировать и поощрять. Если процесс согласования договора прозрачен (чего и позволяет достичь автоматизация документооборота), все понимают, кто за что отвечает и знают, что все действия отражаются в системе, то пропустить согласование договора или пренебречь какой-то порученной операцией уже практически невозможно. А не проработанный договор иногда приносит убытков больше, чем стоимость внедрения СЭД.
Всем угодить
Очень важно понимать, что после внедрения системы не все будут недовольны. К этому просто надо быть готовым и всегда держать в голове цели проекта, ради чего всё затевалось.
Сотрудники привыкают согласовывать документы «физически», бегать по отделам и собирать подписи в бумажном виде (иногда за шоколадку). И, когда в компании автоматизировали документооборот, руководство обычно довольно: поставленная цель обеспечения прозрачности процесса достигнута – полностью отображаются все произведенные операции, бюджеты, факты согласования, отчеты и т.д. Но пользователи недовольны: как же это так, ведь теперь нельзя просто вбежать в кабинет к приятелю из бухгалтерского отдела и наскоро согласовать договор – теперь нужно ждать, пока все согласуют договор в системе. Теперь все действия проверяются по цепи вплоть до директора отдела (как оно, естественно, и должно было быть), и можно отследить, кто, сколько и на что тратит – полный контроль, все действия отражены в системе. А полный контроль не любит никто.
Здесь важно занять жесткую позицию и смириться с тем, что всем угодить невозможно, и цель иной раз все же оправдывает средства. Да, сотрудники могут пошуметь, даже саботировать нововведение, но если руководство непреклонно и соглашается принимать документы только в системе, бунтовщики вскоре будут вынуждены успокоиться и смириться - а что делать?
Грамотным шагом будут переговоры с сотрудниками, объяснение реализуемых действий и донесение всех преимуществ, которые в итоге получит компания после внедрения. А это минимизация ошибок, а, следовательно, меньше штрафов для компании, и бонусы для сотрудников.
Напоследок хочется еще раз заострить внимание на том, что не стоит недооценивать важность СЭД. СЭД не менее важна чем другие, пусть и более масштабные системы, поскольку помогает, в том числе сокращать денежные риски. Так, некорректно согласованные договора могут довести до судебных разбирательств - а это уже и деньги, и время, и доброе имя компании. Однако, к сожалению, далеко не все это осознают, и иной раз приоритет СЭД для компании низок. Руководство выбирает коробочный продукт с ограниченными функциями, полагая, что стандартной функциональности для такой «несерьезной задачи» будет вполне достаточно. Если вы видите в супермаркете дешевую шоколадку за 30 рублей, то вряд ли ваши ожидания от нее будут высокие – это же всего 30 рублей, можно взять попробовать, а если не понравится – выкинуть.
Понимая, что я утрирую, тем не менее у некоторых пользователей может быть подобный поход и к выбору СЭД: взял недорогую «коробку», которая по описанию вроде бы должна выполнять свою функцию - и больше, как тебе кажется, ничего в неё вкладывать не нужно. А потом пользователи удивляются, почему нельзя выполнить какие-то критично важные операции. Поэтому крайне важно осознать всю важность системы и закрываемых ею задач, и подойти к ее выбору серьезно и основательно.
