Эпоха дорогих внедрений прошла - что делать?
Важно, что цель – не сэкономить бюджет, а успешно внедрить систему при имеющихся ограничениях. Пройдемся по всем этапам потенциального проекта и разберем, где и как мы можем существенно снизить затраты.
Стоит ли в очередной раз говорить о повсеместном сокращении расходов – наверно, нет. Внедрение и развитие ИТ-решений продолжает, но в условиях сжатых бюджетов. Да, задача отнюдь не тривиальная, тем не менее даже при таком раскладе у заказчиков есть выбор вариантов автоматизации. Главное – здраво оценить свои силы и готовность к переменам.
В этой статье мы не будем рассматривать внедрение полностью своими силами. Остановимся на том, что сторонний интегратор все-таки привлекается.
Важно, чтобы заказчик осознавал и помнил, что цель – не сэкономить бюджет, а успешно внедрить систему при имеющихся ограничениях. Пройдемся по всем этапам потенциального проекта и разберем, где и как мы можем существенно снизить затраты.
Этап 0. Решение о внедрении, инициация проекта
|
Важно: Еще на нулевом этапе важно выявить заинтересованных лиц среди руководства предприятия. Что это даст: Если мы хотим сократить расходы, нам потребуется поддержка руководства, готовность руководства применять административный ресурс. Это позволит сократить затраты на различные организационные вопросы, бессмысленные совещания и трату сил на преодоление сопротивления части сотрудников внедрению системы. |
Кстати поддержка руководства – это не только способ сократить организационные издержки, но и вообще один из факторов успешности проекта внедрения любой информационной системы. Без нее существенно повышаются риски того, что система внедрена не будет, так как просто некому будет принимать ключевые решения по автоматизации процессов. Итак, если мы хотим сократить организационные издержки, нам потребуется представитель топ-менеджмента, который будет готов «продавливать» решения, которые предлагает проектная команда.
Этап 1. Исследование и проектирование
Стандартный подход к внедрению СЭД зачастую предполагает, что интегратор при исследовании бизнес-процессов и их последующем проектировании ориентируется на концепцию, которую можно было бы назвать «Как вы хотите, чтобы это работало?». То есть исполнитель выявляет все требования заказчика, сложившуюся систему документооборота со всеми деталями и нюансами конкретного предприятия, и далее пытается все это спроецировать на будущую информационную систему. Естественно, что все эти детали и нюансы и составляют большую часть модификаций стандартной версии системы.
Часто интегратор в процессе исследования и проектирования предлагает внести некоторые корректировки, которые основываются на его опыте и лучших практиках, но в половине случаев такие предложения просто не принимаются. Аргументация проста – «у нас работает именно так, мы платим деньги, чтобы вы нам это сделали в системе».
|
Важно: Как вы, наверное, уже поняли, способом сэкономить трудоемкость здесь станет изменение похода к внедрению. То есть необходима переориентация на стандартный функционал системы, готовность адаптировать и изменять процессы под базовые возможности, с минимальной кастомизацией. Что это даст: Мы сможем отказаться от длительного изучения процессов и их детального проектирования с фиксацией конечной реализации в многостраничных проектных решениях. Грубо говоря, все исследование может уложиться в несколько моделирующих сессий, на которых будет продемонстрирован стандартный функционал системы и принято решение о внесении заказных изменений. |
Заказные изменения не должны быть объемными или содержать сложную логику. Чем сложнее логика вносимых изменений, тем больше риск, что без детального проектирования решение будет не жизнеспособным. Если эти изменения в стандартном функционале не существенны, то с большой долей вероятности не потребуется их детально документировать, зачастую достаточно закрепить их на концептуальном уровне.
Естественно, чтобы подстроиться под систему потребуется менять процессы. Вот тут нам и потребуется поддержка руководства, о которой мы говорили ранее. Кстати, изменение процессов отнюдь не является негативным событием в жизни компании. Наоборот, такие изменения могут существенно упростить и ускорить процессы.
|
Важно: Надо понимать, что не все пожеланий будут учтены и людям придется перестраиваться. Если мы хотим сэкономить на исследовании и проектировании, нужно еще на этапе продажи принять решение о готовности меняться под систему и выстраивать оценку стоимости и весь проект на основе этого принципа. Что это даст: Такой подход может являться компромиссным в условиях жестких финансовых ограничений. Если говорить о цифрах, то мы сможем сэкономить до 60-70% трудоемкости на этапе исследования и проектирования. |
Этап 2. Модификация и адаптация
Ориентируясь на стандартный функционал, мы, конечно же, снижаем не только стоимость исследования и проектирования, но и стоимость разработки. На ряде проектов мы опробовали следующий подход: в договор заложили небольшое фиксированное число часов на модификацию (обговорив это на этапе продажи), и в результате реализовывались только приоритетные требования.
|
Важно: Так как мы не вносили существенных изменений в стандартный функционал, то мы вполне можем отказаться от тестовой эксплуатации, на которой представители заказчика тестируют процессы имитацией на предмет соответствия проектным решениям и методам реальной работы. Вместо этого, достаточного трудозатратного этапа, мы также можем провести ряд демонстраций системы, показав рабочей группе, каким образом были реализованы зафиксированные на первом этапе пожелания. Что это даст: Таким образом, мы сможем сэкономить до 50% трудоемкости по сравнению с полноценным, максимальным внедрением СЭД. |
Этап 3. Опытно-промышленная эксплуатация
Опытно-промышленная эксплуатация каких-либо серьезных изменений не претерпит. Значительно сократить стоимость проекта здесь позволит максимальное участие сотрудников предприятия в качестве консультантов.
|
Важно: Необходимо выстроить многоуровневую поддержку, при которой рядовые пользователи обращаются к тем, кто прошел углубленное обучение (например, 1 человек на отдел). Ведущие пользователи, в свою очередь, обращаются к администраторам системы. Если и администраторы не в силах решить вопрос, то он эскалируется к представителям интегратора. Что это даст: Такой подход позволит не только значительно сократить долю участия (а значит и стоимость) исполнителя в опытной эксплуатации, но и позволит создать центры компетенций, которые потребуются для сопровождения системы после завершения проекта внедрения. Это потребует непосредственного участия сотрудников предприятия во внедрении системы, поэтому стоит оценить плюсы и минусы подобной работы еще на старте проекта. |
***
Перечисленные варианты сокращения стоимости, по моему опыту, позволяют сократить трудоемкость проекта на 40-50%. При этом, как я неоднократно писал выше, потребуется менять бизнес-процессы, принимать решения об изменениях, лоббировать эти изменения на всех уровнях. Естественно, остается риск, что сотрудники предприятия не примут нововведения, откажутся от работы в системе. Чтобы минимизировать такой риск, необходимо выбирать СЭД, базовый функционал которой максимально приближен к действующим регламентам. И, конечно, важно максимально включаться в работу в ходе проекта, не ждать, что все будет реализовано исполнителем.
С большой долей вероятности такой подход не подойдет крупным холдингам, производственным предприятиям с делопроизводственными традициями, уходящими в советское прошлое, государственным и муниципальным органам. Достаточно быстро и легко подобные подходы к внедрению реализуются на предприятиях, где нет накопленных десятилетиями традиций делопроизводства и документооборота. В первую очередь это молодые предприятия малого и среднего бизнеса, с общей численностью 200-300 пользователей, готовые к переменам и новым способам повышения эффективности.
Комментарии 2
То есть при покупке системы Заказчик не будет до конца понимать, что на выходе у него будет.
Не легче тогда «несколько моделирующих сессий, на которых будет продемонстрирован стандартный функционал системы и принято решение о внесении заказных изменений» провести на этапе продаж? И заказчик будет знать за что платит, и исполнитель будет иметь четкие задачи и цели проекта. (А возможно, исполнитель на этапе продаж поймет, что данный вариант внедрения не подходит)!
На мой взгляд в эпоху цифровой трансформации основным посылом при внедрении должна быть автоматизация большинства рутинных операций. Будет ли она дешевле обычного внедрения? Не думаю. Скорее наоборот первоначальные затраты возрастут, но это позволит высвободить время сотрудников на выполнение других, более важных задач и в конечном счете принести прибыть компании, тем самым быстрее окупив внедрение.