Меня зовут Денис Рассохин, я руководитель проектов корпоративного отдела Инфостарт. На эти важные, на мой взгляд, вопросы о переходе я постараюсь ответить в статье.
Мой стаж работы в сфере 1С – 10 лет. Специалист по таким направлениям учета как оперативный контур, управленческий учет, регламентированный учет, производство, бюджетирование. Самый крупный проект, химпроизводство, 800 пользователей, длительность проекта 3 года, 18 выделенных функциональных блоков, роль функционального архитектора. Выполненные работы: сбор требований, разработка бизнес-процессов в нотации “Как есть”, разработка бизнес-процессов “Как будет” (проектирование), разработка архитектуры “Как будет”, разработка структуры нормативно-справочной информации, согласование технических заданий, контроль разработки технических заданий.
Шаг 1. Подготовка сотрудников
Сотрудники – передовая линия в процессе перехода, внедрения новых систем и программных продуктов. Для активных действий в правильном направлении им нужна мотивация. Поэтому в первую очередь предупредите ключевых сотрудников, которые будут работать над проектом, о переходе с текущей системы на целевую, объясните, в чем плюсы перехода для них и для компании.
Затем определите, где есть пробелы в компетенциях, выделите ответственных по каждому направлению: функциональным знаниям, БП, НСИ, архитектуре. Подберите обучающие материалы, а лучше проведите обучающий общеобразовательный курс, чтобы все члены команды правильно понимали значения терминов предметной области.
Все это нужно сделать перед стартом проекта.
Шаг 2. Подготовка данных к переходу в виде БП.
Бизнес-процесс — это определенный набор действий, которые выполняют сотрудники, чтобы создать что-либо имеющее ценность для заказчика, клиента компании, партнера или другого сотрудника, которым нужен результат этой работы. Результатом может быть продукт, услуга, информация или документ. Пример шаблона, как должен выглядеть БП (Рис.1 и Рис.2)
- Пример исполняемой модели BPMN
Рис.1
- Пример неисполняемой модели BPMN
Рис.2
Чтобы сэкономить кучу времени и ресурсов, еще до старта проекта необходимо описать все БП, хотя бы их нарисовать, например, в нотации BPMN в среде программного продукта Visio или в любой другой среде – сейчас на рынке их предостаточно. А чтобы вообще было идеально – описать с методологической точки зрения (пошаговое, текстовое описание, если хотите). Это нужно сделать для того, чтобы процессы хранились в визуальном представлении, а не в головах у владельцев БП или функциональных экспертов. Гораздо легче проектировать новую систему, когда процессы расписаны. Если вы этого не сделаете, то высока вероятность того, что при проектировании вы не учтете и не проработаете какую-нибудь деталь в процессе, от которой все последующие действия будут неактуальны или пойдут не по тому потоку данных.
Зачастую, когда проект уже начат, заказчику не объясняли насколько важно, чтобы все процессы уже были подготовлены к внедрению, так как это основополагающая сущность. На их основании и ведется весь учет, даже если БП не выделяют в явном виде, они все равно есть, просто этого не осознают. Поэтому даем задание каждому подразделению, где ведется учет, составить поименованный реестр всех актуальных и действующих БП, прорисовываем все БП в любой доступной для вас среде, выбираем, в какой нотации будут прорабатываться БП, например, BPMN. Рекомендую также пройти курс освоения нотации, сейчас на рынке их великое множество, и подробно в деталях описываем БП.
Шаг 3. Подготовка реестра данных в виде функций
После того как будут подготовлены и описаны все БП, нужно разработать реестр всех функций и классифицировать их на: нужно продублировать (с рефакторингом – улучшение качество кода), частично реализована (доработать), решается типовыми средствами. Но тут есть один нюанс – для того чтобы провести такой анализ, необходим квалифицированный сотрудник, который хорошо понимает целевую систему. В нашем случае – это целевой программный продукт 1С. Поэтому если у вас есть штатный ИТ-отдел, то такого специалиста можно найти там, либо подготовить его к такой работе с помощью курсов (глубоко ориентированных на предметную область). В любом случае выполнять подобного рода работы – это прямая обязанность ИТ-отдела. Если такого сотрудника нет, его можно привлечь со стороны как фрилансера. В ином случае это ляжет на плечи подрядчика, выполняющего внедрение.
Эта работа необходима для того, чтобы у нас было представление, какие функции придется дорабатывать, какие типовые функции уже реализованы в целевом программном продукте. Это важная часть работы, которая также сэкономит много времени и ресурсов. Почему? Потому что анализ всех функций подразумевает под собой их воспроизведение в целевом программном продукте и их последующая квалификация.
Теперь представьте, что такую работу будет выполнять подрядчик, который впервые видит вашу специфику учета. Несложно догадаться, что у него уйдет много времени: во-первых, на изучение вашей специфики; во-вторых, на воспроизведение всех функций в целевой системе – это очень ресурсоемкое мероприятие. Очень важно понимать, что никто не знает вашего учета лучше, чем ваши сотрудники, коллеги. Если эту работу кто-то выполняет за вас – это "испорченный телефон". И да, воспроизводить нужно не только функции, но и прогонять все БП.
Шаг 4. Нормализация НСИ
Итак, сотрудники обучены, БП и функции подготовлены. Не забудем про нормативно-справочную информацию (далее – НСИ). Для того чтобы еще существенно сэкономить время и ресурсы, нужно провести работы по нормализации (улучшение качества НСИ). В качестве примера возьмем «любимый» всеми справочник «Номенклатура». Зачастую этот справочник ведется без каких-либо правил, условий, никакой структуры – в общем, не должным образом и очень зря. Современные системы учета 1С остро реагируют на неструктурированные данные: взять и просто перенести из одной базы в другую не получится. Точнее, технически это сделать можно, но целевая система не взлетит, потому что вы хаос перенесете из одного места в другое.
Например, в справочнике «Номенклатура» зашито множество параметров. Некоторые из них можно создавать и настраивать под ваш учет вручную, без доработок: например, дополнительные реквизиты и сведения. Поэтому при переходе очень важно в существующей базе почистить этот справочник – дубли, неактуальные позиции, разработать структуру, вычистить неиспользуемые реквизиты, понять, какие позиции потребуется объединить для корректного переноса остатков и т. д.
Но такая работа требует соответствующей квалификации. Нужно знать и понимать все тонкости учета и работы с НСИ как в специфике учета предприятия, так и в целевой системе. Тут нам на помощь должен снова прийти ИТ-отдел. Если компетенции не хватает, то пройти соответствующие курсы. Но специализированных курсов, работ с НСИ – нет, только общее представление как работать с НСИ. Знания о том, как правильно проектировать НСИ, приходят на основании эмпирического управления. Такова реальность.
Что делать, если такого сотрудника нет? Также, как и в случае с реестром данных нужно привлечь со стороны, как фрилансера, в ином случае это ляжет на плечи подрядчика, выполняющего внедрение. А такая работа весьма ресурсоемкая. Представим, что справочник «Номенклатура» включает 10 000 или 50 000 позиций – немалый объем для подрядчика, который впервые видит ваш учет и специфику.
Поэтому сразу выделяем несколько сотрудников на такую работу и потихоньку начинаем ее выполнять.
Шаг 5. Архитектура
Обязательно нужно подготовить системную архитектуру в двух направлениях: функциональная архитектура и техническая архитектура.
Функциональная архитектура необходима для представления о текущей системе учета, где и в какой программе выполняется та или иная функция, как программы взаимодействуют друг с другом. И совсем необязательно это могут быть программы: например, облачные сервисы, маркетплейсы и многое другой. Нарисовать такую архитектуру можно в том же Visio, Draw.io, Fox manager или MS Office.
Техническая архитектура необходима для представления о текущей системе технических средств обеспечения, таких как сервера, компьютеры, периферия и другое.
Все это потребуется для оптимизации потоков данных, локализации учета, организации автоматизированных рабочих мест при разработке целевой системной архитектуры.
Шаг 6. Обновление УПП
В таких вопросах без экспертизы не обойтись. Обновление УПП требуется в случаях, если предполагается использовать типовой механизм переноса данных НСИ и остатков. Но и даже это не является гарантом корректного переноса. Очень много зависит от того, как в целом велся учет. Если регламенты типового учета УПП соблюдались, то перенос будет с ошибками, но количество таких ошибок будет незначительно. Если учет велся без соблюдения регламентов, тогда количество ошибок предсказать практически невозможно и лучше всего использовать шаблоны и обработки для переноса. Если УПП доработана, то нужно взвесить все доработки, читайте разделы БП и функции, а также придется продумывать логику миграции данных, разрабатывать табличные шаблоны данных для выполнения миграции, разрабатывать обработки или использовать существующие с адаптацией под вашу специфику, план миграции данных.
Итак, нужно обновляться или нет? Вопрос целесообразности, если трудозатраты рационально обоснованы. Например, мы будем обновляться, потому что у нас незначительные доработки, и это займет 10 часов, плюс миграция данных после обновления займет 20 часов, и все корректировки, замечания мы отработаем в целевой системе.
А если доработки значительные или процессы взаимодействия со смежными системами сложные, то возникает вопрос, а будет ли обновление рационально обосновано, или проще сразу приступить к работам миграции данных. Например, обновление займет 100 часов, а вот разработать шаблоны и обработки миграции данных – 50, разумно тогда обновление не делать. Поэтому, прежде чем принимать решение, необходимо провести глубокий анализ: читаем разделы БП, функции, НСИ.
Вопрос миграции крайне тяжелый и имеет ряд особенностей и нюансов, поэтому планируется отдельная статья.
Шаг 7. Подбираем программное обеспечение
Вот тут точно без экспертного мнения не обойтись. Причем это должен быть высококлассный специалист в области программного обеспечения и учета в экосистеме 1С. Например, если крупный бизнес, то тут выбор невелик: ERP, Управление холдингом или Управление холдингом + ERP в различных вариациях архитектуры, и можно также прикручивать многочисленные модули расширения учета. Хотя и при реализации проектов для крупного бизнеса может получиться целая «солянка» из ПО.
А вот если малый, средний бизнес – тут поле обширное. Возможных вариантов масса, и многое зависит от специфики компании. Примеры некоторых из: ERP, Комплексная автоматизация (КА), Управление торговлей (УТ), Управление нашей фирмой (УНФ), Розница (Р), Документооборот (ДО). Добавим отраслевой специфики: УТ + Р, ERP + PM (Управление проектами), ERP + Молокозавод и множество других вариации. Вопрос один – «что именно?». Для ответа на него нужно подготовить соответствующие данные, читать вышеизложенные разделы. И не зря я упомянул о высококлассном специалисте, который сможет ответить вам: «вот этот комплекс не нужен, вам достаточно одной программы, потому что вам не требуется столь детальный учет».
Как говорится «сила в мелочах», потому что чем больше деталей в учете, тем больше потребуется нетиповых и нестандартных решений, тем более функциональная архитектура.
Технология управления проектом
В общем, при переходе вы должны ответить на три фундаментальных вопроса: Зачем? Что? Как?
- Зачем это вообще нужно – бизнес-обоснование;
- Что получится в конечном результате;
- Как вы будете это делать, вопрос управления.
Остановимся на вопросе «как».
Очень важно правильно организовать переход, а для этого используются различные технологии управления проектами: например, водопад, итеративный подход, гибкие или гибридные. Описывать каждую технологию не имеет смысла для этого есть целые институты. Я лишь хочу сказать, что для этого понадобится кросс-функциональная команда и руководитель проекта, который хорошо понимает тонкости управления проектами. Отмечу, что такие работы ложатся на плечи ИТ-отдела при условии, что там есть соответствующие компетенции.
Что делать, если таких компетенций нет? Можно привлечь фрилансера для управления проектом, но это не всегда правильно: переход – штука очень сложная и требует большого внимания не только к техническим аспектам, а, в первую очередь, к людям. Именно люди являются ключевым ресурсом, именно люди выполняют работы по переходу, и их нужно должным образом мотивировать, вдохновлять. Поэтому лучше всего, чтобы это был человек из команды. Я хочу сказать, это должен быть штатный сотрудник – как на стороне заказчика, так и исполнителя.
Уникальное место для поиска такой команды – INFOSTART.RU
Итог
Подведем черту:
- Шаг 1. Первым делом определяете, достает ли вам компетенций выполнить подготовительные работы к переходу. И начинаете готовить сотрудников.
- Шаг 2. Затем приступаете к выделению и структурированию данных по бизнес-процессам.
- Шаг 3. Как продолжение шага №2, декомпозируете данные на мелкие составляющие.
- Шаг 4. Улучшаете качество всей НСИ, и, как следствие, стандартизируете процессы ввода НСИ.
- Шаг 5. Оформляете схематично системную архитектуру.
- Шаг 6. Определяетесь с решением об обновлении действующей системы.
- Шаг 7. Подбираете целевое программное обеспечение.
Это, тот необходимый базовый минимум, который компания без привлечения подрядчика в состоянии выполнить самостоятельно, сэкономив немало времени и ресурсов.
Отмечу, что планируется серия статей на основании обсуждения вышеизложенной статьи в комментариях. Какие направления из статьи вам было бы интересно развернуть в деталях? Какие темы не представленные в статье вам еще интересны?
Конечно же, есть и дальнейшие шаги реализации перехода по проектной технологии, но текущая цель – подготовиться к переходу, осознать, что переход необходим, чтобы идти в ногу со временем. В итоге переход принесет значительные улучшения не только компании, но и всей экономике в целом.
Благодарю за уделенное вами время! Успешных вам переходов и внедрений!
