С чего начать внедрение 1с erp
Перейти к содержимому

С чего начать внедрение 1с erp

  • автор:

Внедрение 1С: ERP: с чего начать

Аббревиатура ERP (анг. Enterprise Resource Planning) дословно с английского переводится, как планирование ресурсов предприятия.

Определение современной ERP-системы в наиболее полном виде говорит о том, что это эффективная организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения (ПО), обеспечивающего общую модель данных и процессов для всех сфер деятельности.

Вкратце, любая ERP – это информационная система для управления всеми бизнес-процессами и ресурсами компании на основе единой базы данных.

Все системы ERP предназначены для хранения и обработки большого объема данных, позволяют связать все информационные ресурсы предприятия в единую информационную среду, которая позволит более грамотно распределять производственные ресурсы и принимать точные управленческие решения на основе актуальных данных.

Благодаря встроенным модулям ERP-системы можно планировать и оптимизировать все виды ресурсов – финансовые, материальные, человеческие, временные и др.

Если на предприятии уже работают системы учета, управления персоналом, финансами и т.п., это не значит, что они полноценно заменяют ERP-систему, учетные системы охватывают работу только одного подразделения, а ERP-система нужна, чтобы объединить все бизнес-процессы компании на одной мощной платформе. Это позволит снизить затраты, вести точный учёт складских запасов и финансов, исключить брак и увеличить скорость сборки заказов.

Статьи экспертов

Поначалу для каждого автоматизированного рабочего места (АРМ) были составлены подробные инструкции. Оказалось, что эта важная и нужная работа не помогла достичь запланированного результата
Читать дальше

Резервное копирование 1С баз Восстановление 1С PostgreSQL pgAdmin bat-файлы

Автоматизация работы технолога мясо- и рыбокомбинатов «1С»

Автоматизация работы технолога мясо- и рыбокомбинатов «1С»

Руководитель развития решения «1С» для мясо- и рыбокомбинатов Дарья Чернышёва о возможностях автоматизации для специалистов-технологов.
Читать дальше

1С Раздолье 1C 1С ERP РКМ ГОЗ расчёт себестоимости гособоронзаказ автоматизация 1СERP 1СЕРП Плановая калькуляция Фактическая калькуляция

В какие сроки можно запустить блоки плановой и фактической калькуляции в «1С:ERP»?

В какие сроки можно запустить блоки плановой и фактической калькуляции в «1С:ERP»?

Нас спрашивают о сроках внедрения отдельных блоков модуля РКМ [автоматизация подготовки расчётно-калькуляционных материалов по гособоронзаказу], разработанного нашей командой.
Читать дальше

1С Раздолье 1C 1С ERP РКМ ГОЗ расчёт себестоимости гособоронзаказ автоматизация 1СERP 1СЕРП Плановая калькуляция Фактическая калькуляция

С чего начать внедрение «1С:ERP»: подготовка, этапы, рекомендации

С чего начать внедрение «1С:ERP»: подготовка, этапы, рекомендации

С чего начинаются успешные проекты внедрения и с какими проблемами сталкиваются предприятия, успешно прошедшие очередной этап автоматизации? – Рассказывают директор по информационным технологиям АО «Пермский завод «Машиностроитель» Олег Фофанов и ведущий аналитик проекта, специалист ВЦ «Раздолье» Александр Иконников.
Читать дальше

ГОЗ РКМ Подготовка РКМ 1С:ERP Налоговый мониторинг кейс вебинар 1С:ERP Лоцман интеграция 1С:ERP Полином интеграция

Вопросы по модулю РКМ для сложного расчёта себестоимости

Вопросы по модулю РКМ для сложного расчёта себестоимости

Нас спрашивают о возможностях модуля РКМ [автоматизация подготовки расчётно-калькуляционных материалов по гособоронзаказу], разработанного нашей командой.
Читать дальше

1С Раздолье 1C 1С ERP РКМ ГОЗ расчёт себестоимости гособоронзаказ автоматизация 1СERP 1СЕРП

Возможности «1С:Предприятие 8. ERP Управление мясоперерабатывающим предприятием»

Возможности «1С:Предприятие 8. ERP Управление мясоперерабатывающим предприятием»

Презентация обновленного отраслевого решения для предприятий мясопереработки. Возможности решения.
Читать дальше

1С Раздолье 1C 1С ERP Учёт курсовых разниц Курсовые разницы в 1С Учёт валют Курсовые разницы

Учёт курсовых разниц в 2022 и 2023 году. Как применять 67-ФЗ? Практика учёта в «1С:ERP»

Учёт курсовых разниц в 2022 и 2023 году. Как применять 67-ФЗ? Практика учёта в «1С:ERP»

Рассмотрим, как считаются курсовые разницы, что изменилось с принятием ФЗ № 67 с уточнениями на 2022, 2023 годы, и как работать с учётом курсовых разниц в «1С:ERP».
Читать дальше

1С Раздолье 1C 1С ERP Учёт курсовых разниц Курсовые разницы в 1С Учёт валют Курсовые разницы

Межцеховое планирование в «1С:ERP», или Когда уровень MES не нужен

Межцеховое планирование в «1С:ERP», или Когда уровень MES не нужен

Хотя эта статья не является пошаговым учебным инструктажем, все же многим будет полезна. В ней мы, команда Внедренческого центра «Раздолье», поделимся опытом внедрений и расскажем о решениях, которые принимаем на проектах, связанных с межцеховым планированием.
Читать дальше

1С Раздолье 1C 1С ERP Межцеховое планирование Планирование в 1С ERP

Нужно ли докупать лицензии при переходе с «1С:УПП» на «1С:ERP»?

Нужно ли докупать лицензии при переходе с «1С:УПП» на «1С:ERP»?

Предприятия, планирующие переход с «1С:УПП» на «1С:ERP», интересует: как решается вопрос с лицензиями? Постараемся ответить на него кратко и по существу.
Читать дальше

1С ERP Молокозавод Молочное производство Вопрос-ответ внедрение WMS

Как делить налог по ГОЗ и по обычному виду деятельности

Как делить налог по ГОЗ и по обычному виду деятельности

К нам поступил вопрос: Прошу уточнить, как происходит расчёт начисленных налогов, если сотрудник частично получал выплату заработной платы с расчётного счёта организации за выполненную работу по одному заказу и частично со спецсчёта за исполнение ГОЗ. »
Читать дальше

1С Раздолье 1C PDM 1С ERP PDM Автоматизация конструкторского бюро Автоматизация производства 1С

Решить проблемы с путаницей в номенклатуре

Решить проблемы с путаницей в номенклатуре

Один из частых вопросов, который нам задают, касается путаницы в номенклатуре, в нормативно-справочной информации (НСИ).
Читать дальше

1С Раздолье 1C 1С ERP Стоимость запасов Вопрос Ответ

Вопрос по проводкам 41/01.01, 02/41 (ФСБУ)

Вопрос по проводкам 41/01.01, 02/41 (ФСБУ)

– У нас программа «1С:Комплексная автоматизация 2 (2.5.8.295)». Мы воспользовались вашими рекомендациями по поводу перевода основного средства (ОС) в долгосрочный актив к продаже. Столкнулись с проблемой: при переводе в ДАП формируются проводки 41/01.01, 02/41 без учёта счёта 01.09.
Читать дальше

1С ERP Основные средства Вопрос-ответ Статьи расходов и доходов

Использует ли «1С» все ядра процессора?

Использует ли «1С» все ядра процессора?

Поступил вопрос по поводу использования «1С» ядер процессора.
Читать дальше
1С ERP Основные средства Вопрос-ответ 1С Ядра процессора

Почему предприятие молокопереработки UNAGRANDE COMPANY отказалось от WMS

Почему предприятие молокопереработки UNAGRANDE COMPANY отказалось от WMS

Сергей Крохмаль, финансовый директор компании Unagrande Company ( клиент ВЦ «Раздолье») рассказал, почему предприятие решило отказаться от WMS.
Читать дальше

1С ERP Молокозавод Молочное производство Вопрос-ответ внедрение WMS

Вопрос по основным средствам (ОС)

Вопрос по основным средствам (ОС)

– Если ОС числилось за балансом, какие статьи расходов и доходов указать при расторжении старого договора, и какие проводки он формирует? Платежи велись на 76.07.1.
Читать дальше

1С ERP Основные средства Вопрос-ответ Статьи расходов и доходов

Как в «1С:ERP» избежать отклонения в стоимости запасов?

Как в «1С:ERP» избежать отклонения в стоимости запасов?

Продолжаем отвечать на ваши вопросы по работе в «1С:ERP». В этот раз возникла ситуация с отклонением в стоимости запасов.
Читать дальше

Блог компании «СИТЕК»

Проект по внедрению 1С:ERP делится на две основные части:

  • подготовка к внедрению системы;
  • запуск в промышленную эксплуатацию.

В первой части нужно сделать всё, чтобы вторая прошла легко, и пользователи были готовы к работе в новой программной среде. Подготовка включает в себя обследование бизнес-процессов заказчика, моделирование функциональной системы — эдакого примера, по которому заказчик поймет, как будут выполнятся операции по каждому блоку, настройку системы, перенос данных, тестовую эксплуатацию и обучение.

Проект по внедрению ERP

Расскажем подробно о всех этапах: осветим нюансы, на которые следует обращать внимание, скажем о продолжительности этапов и о том, чем должен завершаться каждый из них. А также ответим на вопрос, на какой период года планировать начало проекта?

Обследование

Подготовка к внедрению начинается с обследования. Обследованию может предшествовать экспресс-аудит с проведением стратегической сессии, когда формируется единство определения границ проекта в команде заказчика.

Дальше мы приступаем к полноценному обследованию бизнес-процессов.

Обследование бизнес-процессов

Участвуют специалисты с нашей стороны и со стороны заказчика по каждому блоку учета, которые внедряем. Если внедряем комплексно систему, то речь идет о блоках:

  • регламентированный учет;
  • оперативный учет, включающий товародвижение (закупки, продажи, складской учет);
  • производственный учет, который может быть детализирован, а может ограничиваться только календарным планированием;
  • управление персоналом и расчет заработной платы — блок является частью ERP, но в ряде случаев может быть вынесен в отдельную систему, как и бухгалтерия;
  • управленческий учет.

Также ERP позволяет автоматизировать казначейство, бюджетирование, управление автотранспортом, управление техническим обслуживанием собственного оборудования, требующего профилактики, ремонта, замены. Всё это можно объединить в одной системе!

В результате обследования появляется Устав проекта и Иерархическая структура работ (ИСР). Мы понимаем «как есть сейчас» и фиксируем требования к системе: какие задачи нужно решить, какие неудобства в работе исправить. Определяем цели и границы по каждому функциональному блоку, а также критерии оценки автоматизации: «как мы поймем, что задача решена?», «какие документы, отчеты, показатели должны появится?». Не всегда ответы получаем сразу. Их порой нет даже у заказчика. Чтобы разобраться в ожиданиях от системы и определить истинные критерии, а не выданные наспех для галочки, требуется провести ряд переговоров с будущими пользователями ERP, обратиться к текущей учетной системе или excel файлам, которые заполняют на предприятии. Именно эта работа обеспечивает по итогам проекта ожидаемый клиентом результат. Именно она позволяет настроить систему под конкретное предприятие и конкретных пользователей. В «СИТЕК» мы серьезно работаем с ожиданиями клиента. Внедрить стандартный функционал системы могут разные компании, но далеко не все беспокоятся о результате и о том, чтобы он по-настоящему помогал специалистам, решал задачи предприятия не только в теории, но и на практике.

Обследование длится от 2 до 5 недель. На этом этапе формируются требования к контрольному примеру, который мы будем реализовывать в дальнейшем — на этапе моделирования.

Моделирование

В рамках этого этапа создается функциональная модель системы. Что это значит? В чистой 1С:ERP выполняются верхнеуровневые настройки, вносится минимальное количество данных. Это некая демо-база, приближенная к процессам заказчика. Создаются 2-3 наименования номенклатуры со всеми характеристиками, присущими настоящей номенклатуре предприятия заказчика. Если предприятие производит мебель, то в базе появятся, например, один стул, диван, шкаф, и в характеристиках будут отражены реально используемые параметры (материал, габариты, комплектующие, максимальная нагрузка). Все процессы, описанные на этапе обследования, пошагово вносятся в ERP, чтобы каждый нашел отражение в рамках типовых возможностей системы.

Внесение бизнес-процессов в функциональную модель

Бывает, обнаруживаются процессы, которые нельзя реализовать за счет типовых средств. Тогда мы фиксируем ситуацию, описываем отличие процесса заказчика от типовой логики системы. Выносим вопрос на обсуждение руководству проекта. Рабочая группа со стороны заказчика и со стороны «СИТЕК» принимает решения по каждой из таких ситуаций, которые называются функциональными разрывами. По каждому функциональному разрыву решается: будем дорабатывать ERP-систему, то есть изменять типовой функционал и писать дополнительный код, или заказчик модифицирует бизнес-процесс, приблизив его максимально к типовой логике, зашитой в ERP.

В функциональной модели заказчик видит, как выглядит интерфейс, как происходит движение документов, какие действия необходимо выполнить, чтобы получить тот или иной результат. Документ, описывающий каждое действие настроенное в системе, так и называется — Функциональное модель. Принимается как итог работы по моделированию. Второй документ, получающийся в результате этого этапа — Перечень функциональных разрывов. Он передается в производственную службу, чтобы программисты сделали оценку доработки.

Функциональная модель описана настолько детально, что по этому документу — бери и делай. И действительно, некоторые наши заказчики с сильной IT-службой справляются с настройками своими силами.

Итак, по итогу моделирования заказчик четко понимает, как будет выглядеть система и как она будет работать. Поэтому запуск в промышленную эксплуатацию не станет для него сюрпризом.

Это самое ценное — мы погружаем заказчика с начала работы в возможности системы и трепетно относимся к его ожиданиям.

Этап моделирования длится 4-10 недель.

Настройка системы и доработка по функциональным разрывам

Здесь все действия выполняются на основании функциональной модели. Мы настраиваем ровно то, что смоделировали и согласовали ранее. Параллельно с настройкой системы происходит доработка по тем функциональным разрывам, которые были выявлены на предыдущем этапе.

Перенос данных

Хочется отдельно рассмотреть этот процесс, хотя он выполняется в то же время, что и настройка с доработкой, ведь сложность и значение переноса многие недооценивают. Есть большое количество типовых переносов, которые не дают желаемого качества информации, потому что в результате элементарно могут не совпадать характеристики данных. В своей практике мы обязательно проверяем переносы и чаще всего дописываем их, чтобы не потерять ни один параметр номенклатуры заказчика, ни один элемент учета. Бывает так, что нет никакой возможности перенести данные типовыми способами, например, если использовались какие-то старые системы или не системы 1С, самописные. Тогда перенос полностью пишется.

И вся эта работа должна быть закончена к 31 декабря, потому что ERP-система, если внедряется регламентированный учет, должна внедряться с 1 января.

В другие сроки — можно. Но это «можно» ляжет грузом на плечи бухгалтеров. Ведь большинство отчетов сводится по данным за весь год. Если часть года отработать в одной системе, а другую — в новой, отчетность придется собирать вручную из разных систем. Для крупных компаний это огромный труд и даже риски. Поэтому, когда мы говорим о комплексном проекте ERP, включающем блок регламентированного учета, то в 99% случаев планируем проект так, чтобы 1 января можно было начать полноценную работу в новой системе.

Тестовая эксплуатация и нагрузочное тестирование

Желательно включить в проект этап тестовой эксплуатации, иногда плюсом к нему — нагрузочное тестирование. Что это такое? Это возможность проверить незадолго до запуска в промышленную эксплуатацию полноценно настроенную систему с перенесенными данными на текущую дату. Проверить функциональность тест-кейсами. Это тоже особенность нашей технологии внедрения, которая позволяет на определенных примерах, содержащих усложняющие вводные, проверить работоспособность системы и выдаваемый ею результат.

Нагрузочное тестирование — это проверка работоспособности системы в отягощенных условиях, когда оценивается скорость работы, а в массив обработки данных включается максимально возможное их количество, когда в ограниченный промежуток прогоняются данные за большой интервал времени.

И для тестовой эксплуатации, и для нагрузочного тестирования составляются сценарии, они согласуются «на берегу», до начала работ по этим этапам. Определяются критерии качества: по каким показателям поймем, что тестовая эксплуатация и нагрузочное тестирование прошли успешно.

Обучение

Когда работали по обследованию и моделированию, мы взаимодействовали с командой проекта со стороны заказчика. В нее входят 1-2 человека по каждому блоку учета. Как правило, это функциональный руководитель и ключевой пользователь. Непосредственно перед запуском системы в промышленную эксплуатацию мы проводим обучение уже всех пользователей.

Обучение пользователей

Обучение проводим в разных форматах. Например, в группах, когда преподаватель показывает и рассказывает, как работать в системе, а далее пользователи выполняют примеры, чтобы закрепить полученный материал и задать преподавателю вопросы по ходу практики. По окончании обучения проводится экзамен для того, чтобы определить — готов специалист к работе в системе или нет. Если не готов, то прорабатываются мероприятия для дополнительной подготовки. Делаем инструкции на доработанный функционал. На типовой — их составляет сама фирма «1С». Мы идем в ногу со временем и практикуем видео-инструкции, демонстрирующие экран, отражающие документы, которые надо открыть, на какие кнопки кликнуть.

Запуск в промышленную эксплуатацию

Это время, когда все наши консультанты, работавшие с заказчиком на протяжении всей подготовки к запуску, находятся непосредственно на территории заказчика рядом с пользователям. Пользователи прошли обучение, получили инструкции, но помимо всей этой технологической подготовки нужно учитывать влияние психологических факторов на успешность проекта. В том числе, психологические сложности купируются присутствием наших консультантов по каждому блоку на территории заказчика в момент запуска:

  • специалист по регламентированному учету — в бухгалтерии
  • специалист по бюджетированию — в финансовом отделе
  • специалист по производственному учету — непосредственно там, где вносятся данные по производственному учету
  • специалист по оперативному учету — в отделе продаж, закупки, на складских участках, то есть непосредственно там, где идет оперативное использование системы.

От 2-х недель до 2-х месяцев, в зависимости от количества пользователей и масштабов проекта, наши консультанты работают на территории заказчика. Дальше их присутствие постепенно снижается. Сначала они находятся буквально за соседним компьютером. Потом все так же 100% времени доступны для заказчика, но уже удаленно в Skype, Zoom, Telegram и т.п. Постепенно это взаимодействие сокращается.

Если проект большой, содержащий все блоки учета, то период ввода в промышленную эксплуатацию длится 4 полных месяца и заканчивается сдачей квартальной отчетности за первый квартал. По рег. учету критерием того, что система функционирует нормально, является формирование отчетности за первый квартал года. Таким образом, из проекта мы фактически выходим в мае. Если автоматизируется не все блоки, либо как минимум нет регламентированного учета, то длительность проекта может быть меньше, потому что оперативный учет и производственный требуют от 1 до 3 месяцев запуска.

Оптимальное время для старта проекта — середина года, июнь-июль.

Часть клиентов, которые не понимают, что запуск системы должен происходить 1 января, начинают интересоваться внедрением ERP после летних отпусков, осенью. В таких случаях мы отвечаем, что осталось мало времени для подготовки к запуску. Предлагаем перенести проект на следующий год. Некоторые компании соглашаются отложить задачу, кто-то находит других подрядчиков, решающихся на экстремальный запуск. Но мы понимаем, удовлетворенных заказчиков от экстремального запуска обычно не бывает. Поскольку нам важен качественный результат работы, не беремся за экстремальный запуск.

Узнайте подробнее о внедрения 1С:ERP на странице с описанием услуги.

Компания «СИТЕК» оформит 1С:ИТС за один день в любом регионе РФ

Автор статьи: Елена Лоренцова — коммерческий директор компании «СИТЕК». Дата обновления статьи: 10.11.2020 г.

C чего начать внедрение ERP

C чего начать внедрение ERP

В прошлой статье я рассказывал о том, Что такое ERP система, а также о том, в каких случаях внедрение этой программной системы принесет реальную пользу, и на что обращать внимание при выбореERP. А сейчас я хочу поговорить о том, как получить практическую пользу от ERP-системы. А для этого программный продукт необходимо внедрить.

Я уже писал о внедрении программных продуктов в серии статей «Внедрение программного продукта. Особенности работы бизнес-консультанта». И многие рекомендации из этой серии статей можно применять также при внедрении ERP. Но все же эта система предназначена для среднего и крупного бизнеса, а потому и внедрение ее имеет определенные особенности из числа тех, что в прошлых статьях, посвященных преимущественно малому и среднему бизнесу, я не раскрывал. Еще одна важная особенность ERP – это многофункциональная, сложная система с очень широким функционалом, и при внедрении этот факт также необходимо учитывать.

Скачать книгу Внедрение программного продукта

Самый важный вопрос, который возникает накануне внедрения любой программной системы, это «с чего начать»? Если вы знаете, как и с чего начинать внедрение, и начнете работу правильно, скорей всего, процесс пройдет без лишних сложностей, переделок и конфликтов. А результат оправдает ожидания бизнеса.

О том, как вести проект внедрения ERP-системы от и до, я также постараюсь рассказать в следующих статьях. А сейчас я хочу поговорить о самом важном – начале внедрения.

Разные подходы к внедрению

Существует несколько подходов к внедрению ERP-систем, которые я видел в чужом исполнении и/или сам применял на практике. Каждый из них имеет свои плюсы и минусы, какие-то «подводные камни» и преимущества.

В принципе, все подходы к внедрению ERP, также актуальны для любых сложных систем, например, 1C УПП, 1С ERP, SAP Bussines ONE, ODOO и др. Давайте о них поговорим подробно.

Подготовка технического задания

ERP-система – это продукт очень технологичный. А потому как у разработчиков, так и у бизнесменов очень часто возникает соблазн по максимуму распланировать внедрение еще до начала работ. Казалось бы, все логично. При таком подходе исходят из того, что технологическая программная система должна быть максимально алгоритмизирована. И к процессу внедрения можно и нужно подходить с точки зрения алгоритмизации и математической модели.

Как это реализуют:

  1. Создается объемное техническое задание, в котором по максимуму продуманы и описаны все процессы, включая самые мелкие.
  2. Под техническое задание создается календарный план работ.

На составление подобного технического задания могут уйти месяцы. Я лично видел, как специалист составлял техническое задание по внедрению ERP в течение полугода. В этот период он регулярно выезжал на объект, вникал во все нюансы и вносил их в документ.

От такого подхода плюсы получают, прежде всего, разработчики:

  • Документ Техническое задание будет стоить дорого. Выполняется большой объем работы, занимающий значительное время. И заказчики обычно соглашаются с высокой ценой техзадания без каких-либо вопросов.
  • Разработчики получают подробную инструкцию, на основе которой можно проводить работы. А в случае неудачных решений, имеющихся в подписанном ТЗ, переделки будут оплачиваться отдельно.

Минус подхода заключается в его объеме и сложности. Создать всеобъемлющее техническое задание, в котором будут предусмотрены все модули, документы, все нюансы будущей работы невозможно. Система многофункциональна, и любые изменения в одном модуле могут повлечь за собой необходимость внести изменения в другой.

Аналогично и с ошибками при составлении технического задания: любые неправильные решения в одном модуле могут повлечь за собой множество изменений в других. Например, какой-то бизнес-процесс мог быть понят не верно, и тогда при внедрении выяснится, что часть документации и справочников – не нужны, а требуются совсем другие. Слишком большой объем информации, слишком высокая сложность системы – в результате, оказывается невозможно заложить изначально все нюансы и предусмотреть все возможные ошибки.

В моей практике был случай, когда я пришел на предприятие обсуждать внедрение нового программного продукта (я был руководителем проекта), и мне представители бизнеса прямым текстом говорили: «Хватит с нас технических заданий. У нас этих документов уже – больше, чем надо». И действительно, показали объемные папки с документами, решения из которых так никогда и не были реализованы.

«Частичное» внедрение

В этом случае составляют список наиболее значимых для бизнеса направлений и модулей для работы с ними. На их основе составляют некий план внедрения, который и является основой для начала работ.

В этом случае техническое задание также имеется. Как и календарный план при варианте работы, где за основу берут объемное ТЗ. Но здесь техническое задание не является таким всеобъемлющим, возможно составление для разных этапов работы собственных технически заданий. Т.е. основной документ в данном случае – План выполнения работ.

В качестве первого этапа внедрения выбираем участок Финансы и Движение товаров. Этот участок работ является очень важным для любой компании. Разбираемся с особенностями движений финансовых в организации, изучаем хранение и продажу товаров. На основе этого составляем ТЗ для автоматизации в ERP выбранного участка. И внедряем необходимый для этого участка функционал.

На следующем этапе выбираем другое направление, например, производство. И также работаем с этим направлением плюс учитываем проведенные работы (и возможные доработки) в уже готовых модулях, относящихся к финансам и продукции.

Основное преимущество такого метода – реалистичность. Охватить все и сразу крайне сложно. Внедрять поэтапно – намного проще, ошибок при этом обычно допускается меньше. И результаты работы видны уже в процессе внедрения. Я и сам чаще всего выбираю этот подход.

Минусы – увеличение сроков, которое заказчик может рассматривать как затягивание. При частичном внедрении сроки проведения работ могут затягиваться как по объективным причинам, так и по разных поводам, связанным с финансированием, человеческим фактором и т.д. Кроме того, если руководитель бизнеса стремится получить все и сразу, его также может не устроить отсутствие точных данных о внедрении (когда будет завершено, какова будет точная сумма и т.д.).

Этот метод работы очень осторожный, и чаще всего требует времени больше, чем при других вариантах внедрения. Так, если при первом подходе (составлении ТЗ) все сроки и суммы рассчитаны заранее, до начала работ, то здесь все предварительные цифры примерные. А технические задания для разных этапов составляются в процессе внедрения.

Также при первом методе работы по автоматизации работы разных подразделений могут проводиться параллельно. Клиент будет видеть автоматизацию и бухгалтерии, и продаж, и склада, и производства. Здесь же работа проводится этап за этапом. И подразделения подключаются к ERP также по очереди.

«Agile» подход

В этом случае работы по внедрению начинаются сразу без какого-то подготовительного этапа. Казалось бы, это неприемлемо, ERP-системы слишком сложны, чтобы внедрять их без предварительного изучения особенностей бизнеса и составления документации. Тем не менее, на практике я подобную работу видел.

Некоторые разработчики даже в случае ERP-систем действуют по принципу «начнем, а потом разберемся». Согласно этому подходу создается предварительно общий план внедрения, который по мере необходимости делится на мелкие части.

Чаще всего подобный метод работы практикуют продавцы «коробочных» программных продуктов. Причина заключается в том, что прибыль от продажи «коробки» они получают в любом случае, а внедрение для них – только сопутствующая услуга.

Основной плюс такого метода – работа по внедрению начинается сразу после принятия решения. Без длительной подготовки. Именно это и привлекает бизнесменов. Например, было принято решение – автоматизируем отдел продаж – сразу приступили к работе. Решили – надо перенести остатки – тут же они переносятся.

В принципе, успешное внедрение по такому принципу также вполне возможно. Но это очень сложно и для успеха потребуется очень высокий уровень профессионализма руководителя, а также значительный опыт внедрения подобных проектов. И даже в этом случае профессионалы чаще выбирают другие пути. Просто потому, что они позволяют снизить число ошибок и накладок, влияния человеческого фактора. В итоге, варианты работы по ТЗ или внедрения по частям позволяют получить нужный результат с меньшим количеством накладок и переделок.

Минусы – отсутствие планирования комплексного внедрения. Здесь проблемы возникают практически по тем же причинам, что и при составлении всеобъемлющего ТЗ: ERP – сложный комплексный программный продукт, и ошибки при внедрении одного модуля могут повлиять на работу другого модуля. Но если в первом случае такие проблемы возникают из-за попытки заранее предусмотреть слишком много, то здесь – по причине отсутствия планирования. Т.е. специалисты при внедрении решают сиюминутные задачи, не задумываясь о том, что на следующем этапе им потребуются данные и документы из текущего модуля для организации работы другого подразделения.

Еще один минус – при таком подходе вовлеченность сотрудников компании в процесс внедрения значительно ниже, чем при любом из описанных выше. Это отрицательно сказывается на решимости сотрудников принимать участие в тестировании и переходе на новую систему, а также провоцирует саботаж использования новых инструментов.

«Понемногу, но все и сразу»

Еще один подход к внедрению ERP я лично называю “Понемногу, но все и сразу”. Этот вариант также вполне может быть успешным и удобным решением. Я лично его применял не один раз. И если при частичном внедрении в работу берут один или два модуля, полностью их настраивают, и только потом приступают к работе над другими модулями, то в этом случае работа также ведется постепенно, то нет такого четкого ограничения — только этот модуль и никакие другие.

При таком подходе первым делом также составляется план проекта. В этом плане основными этапами считаются не модули (один, потом — другой и т.д.), а какие-то виды работ, которые могут затрагивать одновременно все модули или выборочно какие-то из них. При этом для каждого этапа указываются примерные сроки и стоимость.

В самом общем случае подобный план выглядит следующим образом:

  1. Разработка технического задания.
  2. Выполнение работ согласно технического задания… Этот пункт может быть детализирован, выполнение работ тогда делится на несколько этапов.
  3. Тестирование системы.
  4. Ввод в эксплуатацию.
  5. Обучение персонала.
  6. Завершение (сдача) проекта.

Подобный план составляется и отдельно для каждого модуля, что позволяет максимально конкретизировать для заказчика стоимость каждого этапа работ, а также наиболее точно определить возможные сроки. При этом с заказчиком обязательно оговаривается возможность в процессе внедрения в случае необходимости изменить какие-то виды запланированных работ другими.

Такой метод удобнее и реалистичнее, чем составление технического задания, так как общее ТЗ для всего проекта потребует 2-3 месяцев работы или даже больше, а полученный в результате объемный документ со всеми подробностями заказчику изучить будет очень сложно.

Здесь заказчик видит план со сроками и суммами для каждого этапа. А техзадания под каждый этап работ создаются отдельно, они небольшие и не требуют значительных временных затрат. Желательно еще и называть каждый из документов понятным образом. Например, «Бухгалтерия и финансы» или «Отдел продаж».

Плюсы такого подхода:

  • Заказчик сразу видит весь проект целиком. С максимально точными сроками и стоимостью, насколько это вообще возможно до начала внедрения.
  • Исполнитель четко определяет бюджет каждого этапа и выставляет счет для оплаты. При этом сумма счета не вызывает никаких вопросов, что позволяет продуктивно работать, не отвлекаясь на обоснование счета или подсчет количества затраченных по факту часов.
  • Заказчику необходимо очень тщательно выбирать исполнителя, чтобы руководитель проекта на должном уровне разбирался в особенностях внедрения каждого модуля. Иначе расчеты в плане окажутся недостаточно точными. Бюджет может неожиданно увеличиваться, сроки растягиваться, т.е. основные преимущества подхода будут потеряны.
  • Исполнителю потребуется значительное количество высококвалифицированного персонала, чтобы уложиться в сроки и заниматься параллельно разными модулями. Т.е. небольшая команда такой подход не сможет реализовать.

Важная особенность планирования: При подсчете бюджета независимо от вашего опыта и точности оценки следует “заложить” дополнительную сумму на случай непредвиденных ситуаций. Оптимальный размер такой суммы — 30% от стоимости запланированных работ. Это можно назвать согласованное планированное отклонение стоимости проекта. Эти средства могут потребоваться при возникновении каких-то сложностей — организации обмена данными с программой, которая не поддерживает существующий API, доработка базовых справочников, сложности при переносе данных, реализация необходимых для работы функций, которые по той или иной причине не сумели предусмотреть заранее и т.д.

Эти 30% учитываются в бюджете, но выплачиваются исполнителю только в случае необходимости. Если вы при реализации проекта сумели уложиться в базовые цифры бюджета без «резерва», прекрасно! Заказчик будет благодарен, а довольный клиент — это и новые заказы, и лучшая реклама по «сарафанному радио» (рекомендации друзьям и знакомым).

Если все же понадобится использовать резерв, очень важно грамотно и понятно обосновать, на какие работы потребовались эти деньги. Включать же эту сумму в бюджет нужно для того, чтобы не возникало неприятных ситуаций, когда бюджет увеличивается, а у заказчика такая статья расходов не предусмотрена.

С каких модулей начинать?

Количество модулей, которые может предложить систем ERP, вызывает нередко вопросы, с чего же начать, ведь возможностей очень много, как говорится, «глаза разбегаются». Я рекомендую начинать с наиболее критичных для работы компании направлений и связанных с ними модулей:

  1. Финансы и взаиморасчеты. (Не путайте с бюджетированием – этот модуль можно и нужно внедрять позже, он относится к планированию, а не к текущей критически важной работе).
  2. Движение товарно-материальных ценностей (ТМЦ): хранение, реализация, поступление. Очень важно, чтобы ТМЦ учитывались корректно, перед переносом остатков обычно проводят инвентаризацию, далее – переносят остатки, после чего работа ведется уже только в новой системе.
  3. Бухгалтерский учет. Внедрение модуля бухучета или организация обмена данными с бухгалтерской системой. Государство ничего не прощает, и за любое нарушение, независимо от наличия умысла, предусмотрено наказание. А потому бухгалтерский и налоговый учет – также система, критичная для работы любой компании.

Иногда я слышу возражения, что у компании могут быть свои нюансы, например, в связи с высокой текучкой кадров наиболее критичным является HR. На самом деле, скорей всего, какая-то автоматизация работы HR в компании на момент начала внедрения ERP имеется. И независимо от того, насколько критична для бизнеса работа этого подразделения, некоторое время управление персоналом можно будет вести в той системе, которая есть. А если в процессе будут выявлены определенные ошибки – это будет минусом, но не самым критичным для существования компании.

Также и проектный отдел или маркетинг какое-то время смогут работать в привычном режиме и вести учет автономно в той системе, которой они пользовались ранее.

В то же время строгий учет и контроль движения основных ценностей (финансовых и материальных), а также отсутствие ошибок в бухгалтерском и налоговом учете – это те «столпы», без которых не сможет существовать ни одна компания.

Я надеюсь, что материал о том, с чего стоит начинать внедрение ERP, и какие методы работы с этой системой практикуются, был вам полезен. В следующих публикациях я расскажу о своем личном опыте внедрения ERP, поделюсь информацией об ошибках, которых лучше избегать, а также о том, на что нужно обращать внимание в процессе внедрения и как лучше построить эту работу, чтобы переход на ERP был максимально эффективным.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *