Я хочу обсудить взаимодействие автоматизаторов и консалтеров в проектах автоматизации учета. Мы рассмотрим эту тему на локальном примере – автоматизация учета затрат и расчета себестоимости. Это многим знакомая область, в которой бывают простые ситуации, а бывают довольно сложные. На крупных проектах внедрения информационных систем, связанных с учетом, консалтеров часто привлекают для написания методологии по учету затрат. Посмотрим, к чему это приводит на практике.
Если говорить о «чистом» консалтинге, то цели и польза консалтеров на проектах, не связанных с автоматизацией, обычно интуитивно понятны. Они помогают разобраться в методологических проблемах, разработать методику работы, которая формализует процессы, улучшает выполнение учетных задач, снижает риски – в том числе фискальные – и решает другие проблемы.
Консалтеры могут помочь унифицировать НСИ на уровне предприятия или выработать единые стандарты и подходы для группы компаний в холдинге. Это особенно важно как раз для групп предприятий, чтобы получать корректную, сопоставимую отчетность, понятную руководству холдинга. Еще одна типичная задача – подготовка к аудитам. В области учета консалтеры умеют делать это хорошо.
Семь пунктов, которые отражают основные результаты их работы:
-
обеспечить целостность и непротиворечивость данных,
-
гарантировать соответствие данных требованиям законодательства и внутренним стандартам компании,
-
упростить процесс принятия управленческих решений,
-
повысить эффективность работы бухгалтерии и других подразделений, отвечающих за учет,
-
снизить риски ошибок и злоупотреблений,
-
улучшить качество отчетности,
-
повысить инвестиционную привлекательность компании.
Разработанные методики и методические подходы направлены на достижение именно этих целей.
Изменение целей консалтинга в контексте автоматизации
Теперь посмотрим, что происходит, когда консалтеров привлекают в проект автоматизации. Цели такого привлечения и задачи, которые ставятся перед консалтерами, во многом, другие.
Основная задача заключается в разработке правил и методик, которые, с одной стороны, позволяют сформировать требования для автоматизации, а с другой – подготовить нормативные документы, обеспечивающие использование внедренной информационной системы в соответствии с ее настройками, регламентами и положениями.
Если рассмотреть это внимательно, цели таких проектов заметно отличаются от целей обычных консалтинговых проектов. Посмотрим, к чему приводит эта разница.
Цели заказчика при привлечении консалтеров
Заказчик задумывает проект автоматизации (в данном примере) учета затрат и расчета себестоимости и привлекает консалтеров. Возникает вопрос – зачем? Главная цель заказчика в большинстве случаев – облегчить внедрение системы, передав часть задач консалтерам.
Консалтеры должны помочь сформулировать требования к системе, принять настройки от интегратора, а желательно – и всю систему целиком, убедившись, что она соответствует требованиям методологии, применяемой на предприятии. Вторая цель заказчика – поддержка проекта автоматизации: разработка инструкций, положений и правил в соответствии с тем, как процессы реализованы в системе.
Цели выглядят логично, и понятно, за что заказчик платит деньги.
Цели и мотивация самих консультантов
Посмотрим, какие цели преследуют консалтеры, когда входят в такие проекты. Не в консалтинговые проекты по написанию методик, а именно в проекты автоматизации.
Первая задача консалтеров – использовать свой предыдущий опыт и на его основе подготовить методологию для проекта автоматизации. Это логично: чем больше опыта, тем выше качество результата. Но здесь возникает риск – опыт консалтеров чаще всего консалтинговый, а не связанный с автоматизацией. Поэтому методики, которые они разрабатывают, могут не иметь отношения к реальной автоматизации.
Вторая задача/цель – перевести заказчика на дальнейшее сотрудничество: аудиторское или консалтинговое сопровождение. Это естественно и полезно, так как повышает качество услуг, но тоже несет риски. Консалтеры могут попытаться изменить всю систему учета, чтобы обосновать свою будущую необходимость для предприятия. Само по себе это тоже не страшно, но при большом количестве изменений в рамках внедрения информационной системы проект усложняется, сроки сдвигаются, а реализация становится менее предсказуемой.
Есть риск – иногда консультанты пытаются самоутвердиться за счет интегратора, что также приводит к усложнению проекта.
Третья цель – добиться от интегратора реализации проекта с учетом требований методологии. Это основная задача консалтеров, но и здесь есть риск: если консалтер плохо разбирается в информационной системе, он может настаивать на реализации требований, которые бессмысленно или нецелесообразно внедрять. Опытный интегратор, конечно, сможет это отстоять, но это потребует времени, денег и создаст лишнюю напряженность в проекте, хотя цель привлечения консалтеров заключается в том, чтобы упростить взаимодействие IT-интегратора и заказчика на проекте.
Ожидания IT-интегратора от привлечения консалтеров
Почему IT-интегратору может быть выгодно участие консалтеров в IT-проекте?
Здесь все тоже понятно. Когда мы приглашаем консалтеров или входим в проект, где они уже есть, мы рассчитываем получить квалифицированные ресурсы для формулирования требований к системе. У заказчика не всегда есть такие специалисты и не всегда есть возможность их выделить в проект.
Кроме того, консалтеры помогают упростить коммуникацию с пользователями: они говорят с ними на одном языке и при этом понимают IT-специалистов.
Также их участие позволяет получить поддержку для системы в виде регламентов, положений и политик, которые закрепляют внедрение информационной системы.
Почему консалтинг в автоматизации часто приносит больше проблем, чем пользы
Посмотрим, почему участие консалтеров в проектах автоматизации в большинстве случаев приводит скорее к проблемам, чем к пользе.
Во-первых, консалтеры часто не знают продукт. В итоге они не понимают, что от них требуется, и делают то, к чему привыкли: создают многотомные методики на две с половиной тысячи страниц, которые не являются постановкой задач или формулировкой требований для IT-интегратора.
Во-вторых, бизнес консалтеров устроен иначе. Они пишут правильные и красивые документы, предназначенные для того, чтобы обезопасить предприятие от ошибок сотрудников, проверяющих органов и навести порядок в процессах. Но это именно набор документов, а не набор требований к системе. В результате появляются громоздкие документы, которые не помогают проекту автоматизации.
Приведу несколько примеров. Может быть, эти примеры не самые показательные, но их плюс – они взяты с реального проекта.
Вопрос выбора консультантов и реальные примеры документации
В большинстве случаев консультантов выбираем не мы. Ситуации, когда мы сами приглашаем консалтеров, с которыми уже работали и понимаем, как выстроить взаимодействие, редки. Обычно консалтеров выбирает заказчик – тех, кто уже оказывает ему услуги и пользуется его доверием.
Консалтеры готовят большое количество подробных, но бесполезных для автоматизации материалов. Вот пример из реальной методики. В целом текст написан грамотно, но документ занимает 400 страниц, из которых 95% содержат информацию подобного характера.
В этом примере приводятся определения – они, возможно, важны для консалтинговых задач, но не несут пользы с точки зрения автоматизации.
Такие документы – типичная картина для проектов с методологической поддержкой. Если методология стоит, скажем, 10 миллионов рублей, то результатом часто становится именно такая кипа документов. И, если приходится читать подобные материалы, не будучи уверенными, что внутри есть реальные требования, то часто проще напрямую согласовать требования с заказчиком, а эти документы отложить в сторону. Возможно, они нужны заказчику для внутренних целей, но для проекта автоматизации пользы не приносят.
Это – проблема. А теперь перейдем еще к одной, о которой я уже упоминал.
Документы, которые разрабатывают консалтеры, обычно создаются в первые три месяца проекта. Если на этом их участие заканчивается, это становится существенной сложностью. Консалтеры не занимаются авторским надзором – не проверяют, соответствует ли реализованное решение тому, что они описали в методиках, и не несут совместной ответственности с интегратором за результат.
В нескольких проектах, в которых мы участвовали, ситуация повторялась. В итоге мы пришли к выводу, что проще написать методики самостоятельно, даже если это не наша основная компетенция, чем взаимодействовать с таким консалтингом.
Положительный кейс: сотрудничество с внутренними консультантами
Тем удивительнее оказался недавний кейс на одном из проектов по автоматизации учета затрат и расчета себестоимости, где нам удалось эффективно поработать с консультантами. Это были внутренние консультанты заказчика. Они подготовили набор документов и материалов, примеры которых я покажу.
Вся переданная информация включала:
-
схемы в Visio,
-
Excel со списком мест возникновения затрат, счетов учета продукции, выпускаемой предприятиями,
-
Excel с примерами расчета затрат.
Посмотрим подробнее.
На этом примере – реальный документ. Хотя часть данных скрыта, общее представление можно получить. Это схема закрытия затрат по одному из подразделений. По ней аналитик или архитектор проекта автоматизации сразу видит структуру участков внутри цеха, их функции, направления передачи продукции, движение затрат, базы и правила распределения.
У заказчика была такая схема по каждому подразделению и виду деятельности, то есть она полностью охватывала процесс. На основе этих схем мы сразу могли моделировать ситуацию в системе и показывать заказчику конкретные примеры, которые он оценивал с точки зрения соответствия своим ожиданиям.
Еще одно представление – схема движения работ, готовой продукции и полуфабрикатов с цифрами, понятными заказчику. Мы брали эти данные, закладывали их в модель, и заказчик легко понимал суть демонстрируемых примеров.
В Excel-файле с базами общепроизводственных расходов были указаны типы расходов и базы распределения, что помогло избежать потерь данных и не искать ошибки уже в процессе запуска системы.
Тоже полезная таблица – это схема распределения затрат.
Эта информация помогла на старте определить ожидаемые счета учета по затратам. Заказчик хотел минимизировать количество статей, но при этом предусмотреть возможность учета отдельных статей на разных счетах для разных подразделений.
Такой, на первый взгляд, простой объект позволил нам сформировать адекватный справочник статей затрат еще до ввода системы в эксплуатацию. Те, кто сталкивался с подобными проектами, знают, что основная масса изменений обычно происходит уже на этапе запуска системы.
Анализ успеха положительного кейса
Посмотрим, почему методика, которую мы получили на этом проекте, оказалась полезной для автоматизаторов.
Во-первых, это были внутренние консультанты заказчика, и у них не было задачи отработать бюджет. Им не нужно было создавать большое количество документов, чтобы показать ценность своей работы. Их цель заключалась во внедрении информационной системы.
Во-вторых, перед стартом проекта коллеги прошли курсы по 1С:ERP и уже понимали, какие требования нужно формулировать, чтобы автоматизатор мог корректно спроектировать систему. Это были опытные специалисты, ранее работавшие в крупных консалтинговых компаниях.
И главное – их задачей было не просто провести консалтинг и уйти, а довести систему до запуска. Эффективность их работы оценивалась по тому, как будет функционировать система, а не по объему и качеству документации.
Рекомендации заказчику по взаимодействию с консалтерами в проектах автоматизации
В результате можно сформулировать некоторые рекомендации, которые стоит учитывать заказчику при формировании проектной команды, где участвуют консалтеры и IT-интеграторы в проекте автоматизации учета.
Во-первых, необходимо проверить квалификацию консультантов в части участия в подобных проектах. Важно убедиться, что они работали не только в классическом консалтинге, но и в проектах внедрения ИТ-систем. Это можно проверить по отзывам, примерам реализованных проектов, сертификатам – например, «профессионал по ERP» или «специалист-консультант». Наличие таких подтверждений говорит о том, что специалисты смогут задавать правильные вопросы и формулировать корректные требования к системе.
Стоит заранее договориться о формате документов, которые коллеги предполагают передавать интегратору. Если это исключительно методики учета затрат и единые планы счетов – значит, подход не соответствует задачам автоматизации.
И вторая рекомендация – договориться о формате документов, которые будут готовить консультанты. Это можно сделать до начала проекта или на этапе его инициации. Это важно, потому что качество и структура таких документов напрямую влияют на эффективность взаимодействия всех сторон.
Нужно предусмотреть авторский надзор, то есть участие консалтеров в контроле соответствия проектируемой системы требованиям заказчика.
И, наконец, важно предусмотреть мотивацию консультантов на запуск системы. Если консалтеры завершают работу до ввода системы в эксплуатацию, это негативно влияет на результат.
Если следовать этим рекомендациям, можно достичь целей всех сторон – консультантов, заказчика и интегратора – и обеспечить успешную реализацию проекта.
Дополнительный формат сотрудничества: программно-методический комплекс
Расскажу еще об одном варианте сотрудничества консалтинга и IT-интеграторов, который мы сейчас реализуем на практике.
Довольно часто заказчики обращаются к нам с задачей автоматизации управления закупками. Это область, которая слабо формализована: нет единой общепринятой методики, но при этом существует продукт, который фирма «1С» позиционирует как решение для автоматизации управления закупками – как на уровне предприятия, так и на уровне холдинга. Это система «1С:Управление холдингом».
Чтобы не приходить к заказчику с вопросом, на который у него обычно нет готового ответа – например, «Какую методику управления закупками вы используете?» – мы решили использовать методологию наших партнеров-консультантов. Сейчас в «1С:Управлении холдингом» мы настраиваем предопределенные объекты бизнес-процессов заказчика.
Приведу несколько примеров того, что входит в этот программно-методический комплекс, то есть как методология отражается в программном продукте:
Номенклатура закупок
Настроенная структура и группировка:
-
группы номенклатуры
-
товарные категории и т.п.
Статьи расходов на закупку
-
Типовые статьи бюджета и статьи расходов
-
Четкие правила соответствия «номенклатура – статья бюджета/расхода»
Планирование потребностей
-
Правила планирования и обеспечения потребностей в зависимости от вида номенклатуры
Контроль и оценка потребностей
Настроенные правила для каждого вида номенклатуры:
-
требования к экспертизе заявок на обеспечение
-
сценарии согласования заявок и ответственность за корректировку
-
требования по контролю лимитов и правила лимитирования
Планирование расходов
-
Источники финансирования
-
Правила финансирования закупок в зависимости от вида номенклатуры
Выбор поставщиков
-
Типовые закупочные процедуры
-
Правила выбора процедуры и критерии оценки поставщика в зависимости от номенклатуры
И многое другое
По сути, мы берем уже успешную методологию, опробованную на пяти предприятиях, и закладываем ее в продукт. И такой подход, по нашему опыту, делает проект автоматизации закупок максимально полезным для заказчика, сокращает время внедрения и, часто экономит бюджет.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.