Требования к erp-системы

Как правильно выбирать ERP-систему

Оглавление журнала

    Владимир Чаадаев — выпускник МИФИ (специальность — экспериментальная ядерная физика). С 1980 г. занимался разработками научной аппаратуры, систем сбора и обработки информации. С 1993 г. — менеджер проектов в области системной интеграции (сети, базы данных). C 1996 г. работает руководителем проектов и консультантом по финансам в области внедрения ERP. Имеет опыт работы с BAAN, Oracle E-Business Suite, SAP/R3. С 2004 г. основное направление деятельности — организация управления компаниями с применением информационных систем.

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

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

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

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

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

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

Кто и как должен выбирать

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

Не следует полностью передоверять задачу выбора системы сторонним консультантам. Как правило, все компании такого рода сами продают или внедряют какую-либо систему — естественно, с их точки зрения она и окажется наиболее подходящей. Независимых специалистов, хорошо знающих ERP (тем более не одну), практически нет. Вот почему ответственность выбора лежит на самом предприятии. В состав проектной группы по выбору необходимо включить специалистов, в равной степени хорошо знающих бизнес и информационные технологии. Количественный состав группы независимо от масштабов компании не должен превышать четырех-пяти человек. К работе обязательно следует привлекать сотрудников функциональных подразделений. Для решения отдельных вопросов могут приглашаться сторонние консультанты.

Сбор требований к системе

Мы будем рассматривать здесь только функциональные требования, основными источниками которых являются:

  • стратегические цели и задачи компании;
  • оперативные бизнес-процессы;
  • требования финансового учета;
  • сопрягаемые информационные системы.

Все собранные требования следует классифицировать по важности на основе правил ABC-анализа: A — критические, реализация которых необходима; B — важные, от которых можно отказаться в случае большой трудоемкости реализации; С — желательные, от которых можно отказаться без существенных потерь.

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

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

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

Требования оперативного управления

Казалось бы, идеальным описанием требований оперативного управления может стать модель бизнес-процессов. Однако реальные бизнес-процессы производственных компаний очень сложны. Каждый представляет собой множество вариантов действий, связанных с конкретными ситуациями. Попытка описать деятельность компании с помощью моделей бизнес-процессов может повлечь за собой очень большой объем работ. Кроме того, следует учитывать, что при внедрении ERP произойдет их значительное изменение. Это связано с тем, что любая ERP-система разработана в соответствии с бизнес-процессами некоторой эталонной модели, принятой разработчиками за основу, и при внедрении вы невольно будете реализовывать именно их. Поэтому не стоит описывать бизнес-процессы «as is» ни на этапе выбора системы, ни при ее внедрении. Лучшим решением будет построение функциональной модели компании и определение требований к существующим в ней функциям. При создании модели обязательно используйте графические средства — это значительно облегчит работу с ней.

Рассмотрим в качестве примера функциональную модель «Управление основной деятельностью производственного предприятия» (для наглядности показаны только декомпозиция функций и информационные потоки, связанные с бизнес-функцией «Комплектация и отгрузка»). В основе модели лежит иерархическая функциональная структура компании. На рис. 1 приведен верхний уровень модели. На этом уровне обычно представлены функциональные области (ФО) управления компанией. Каждая ФО декомпозируется на бизнес-функции (БФ1). На рис. 2 представлена декомпозиция бизнес-функции «Производство и логистика». Этот уровень будет примерно соответствовать составу пакетов ERP. Следующий уровень декомпозиции (рис. 3) уже соответствует уровню бизнес-функций второго порядка (БФ2). Как правило, большая степень детализации модели не требуется. Каждая из БФ2 реализуется посредством одного или нескольких бизнес-процессов. При построении модели следует приводить только основные информационные потоки — те, что инициируют запуск бизнес-процессов или отражают результат их выполнения.

Для каждой БФ2 выполняется описание ее основных характеристик.

Сущность бизнес-функции. Необходимо дать краткую формулировку, в которой описана основная задача данной функции: «Отбор, комплектация, отгрузка продукции и подготовка товаро-сопроводительной документации (ТСД)».

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

Описания бизнес-процессов. Каждая функция реализуется посредством одного или нескольких бизнес-процессов, например: «Отбор, комплектация и отгрузка продукции железнодорожным транспортом», «Отбор, комплектация и отгрузка экспортной продукции автотранспортом».

Необходимо кратко описать бизнес-процессы, реализующие функцию. Очень удобно использовать для этого модели в стандарте UML (Use Сase). Наиболее важно отражение особенностей, связанных со спецификой вашего бизнеса. Так, по бизнес-процессу «Отбор и комплектация поставок» может быть приведена следующая информация:

  • отбор продукции производится только из свободного и зарезервированного для данного клиента запаса;
  • при комплектации мелкие товары упаковываются в контейнеры, которые являются возвратной тарой и должны быть включены в накладную;
  • при погрузке «поставка» разбивается на «отгрузки» по количеству мест (вагонов или автомобилей). На каждую отгрузку формируются комплект сопроводительной документации и счет-фактура.

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

Метрические характеристики. Обязательно опишите метрические характеристики бизнес-процессов: среднее количество операций в месяц, пиковое количество операций в сутки, количество исполнителей. Особое внимание уделите описанию существующих проблем управления данной функцией.

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

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

Состояние информационной поддержки. В этом разделе нужно описать программные средства, используемые для автоматизации данной функции, и степень автоматизации процессов.

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

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

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

Требования к данным

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

В первую очередь следует обратить внимание на статические объекты, которые, как правило, не изменяются в ходе выполнения бизнес-процессов: «Номенклатурный справочник», «Поставщики», «Клиенты», «Банки», «Склады», «Оборудование», «Производственные спецификации». Наиболее важным из них является «Номенклатурный справочник», который содержит описание позиций товарно-материальных ценностей и услуг, используемых или производящихся компанией. Для каждой номенклатурной позиции справочник содержит массу информации, используемой многими бизнес-функциями. Кроме того, существует ряд непосредственно связанных с номенклатурным справочником объектов: «Партии», «Производственные спецификации», «Производственные маршруты», «Себестоимость». Необходимо отразить в требованиях важнейшие характеристики вашей продукции. В частности, для некоторых типов производства большое значение имеет возможность работы с переменными характеристиками изделий, например длиной или концентрацией раствора. Для таких объектов, как «Поставщики’ и «Клиенты», иногда требуется вести отдельные расчеты по каждому контракту.

Читайте так же:  У кого взять займ под материнский капитал

Динамические объекты — это объекты, информация в которых возникает в результате выполнения бизнес-процессов: заказы, счета-фактуры, складские поступления. Требования к ним, как правило, формируются при подготовке функциональной модели в разделе «Информационные потоки». В качестве примера приведем требование указания в отгрузочных документах физических характеристик конкретной партии продукции.

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

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

Как выбрать ERP-систему и не пожалеть

Как выбрать ERP-решение? Какие вопросы нужно задавать представителям ERP-компаний (и на какие вопросы вы вправе получить полные и исчерпывающие ответы), как не дать ввести себя в заблуждение при проведении презентации ERP-решения? Как довести внедрение ERP-системы до логического завершения?

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

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

Если говорить в среднем, то количество «проваленных» ИТ-проектов в России сегодня около четверти от общего их числа. Но думаю, что я не ошибусь, если назову ERP-внедрения одними из самых провальных, и здесь уже процент успешных внедрений не превышает 15–20%. Почему проекты по автоматизации бизнеса проваливаются?

  • Отсутствие четкой цели, поставленной заказчиком
  • Ошибочный выбор ERP-решения
  • Некачественно сформулированное ТЗ
  • Низкая квалификация специалистов, внедряющих решение, как со стороны заказчика, так и со стороны исполнителя
  • Недостаточный административный ресурс со стороны заказчика.

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

Первое, что необходимо сделать еще до начала поиска ERP-системы — совершенно четко ответить себе на вопрос «Зачем мне это?». Иными словами, четко сформулировать цель, которую необходимо достичь. Так, чтобы при приеме системы от поставщика банально поставить «галочки»: это решено, это решено, а это — нет.

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

Кто выбирает ERP-систему?

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

ERP-система: для кого?

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

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

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

ERP-система — инструмент для принятия решений

На мой взгляд, любое ERP-решение — это, в первую очередь, инструмент для принятия решений. На основании чего принимают решения? На основании отчетов. Вот значит, и один из видов критериев. Отчетность. Система должна давать полноценные отчеты о деятельности компании, которыми являются, например, «Прибыли и убытки», «Движение денежных средств», «Баланс», и многие другие управленческие отчеты. Если эти отчеты будут отражать реальную картину положения дел, то вы без труда разберетесь в проблемах компании, и будете иметь возможность влиять на ситуацию. И если во время презентации вам будут говорить, что в демо-версии эти отчеты просто не настроены, не верьте. Если в системе они есть, их будут показывать в первую очередь. Отчеты обязаны предоставлять не только цифры, но и инструменты для их анализа. Анализировать цифры отчетов можно по-разному, и я не буду здесь заострять на этом внимание. Главное, чтобы вы имели возможность все цифры проверить непосредственно из отчета, т.е. каждую цифру детализировать вплоть до первичных данных непосредственно из отчета. Иначе вы не будете уверены в достоверности данных. Отчетность должна быть прозрачной.

Читайте так же:  Контроль за исполнением приказа образец

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

Важно не только знать показатели деятельности, но и иметь возможность анализировать их динамику и структуру. Показатели нужны не просто для того, чтобы на них смотреть, а для того, чтобы на основе их анализа принимать решения, способные эти показатели изменить. Одно дело, когда вы видите, что дебиторская задолженность клиентов в этом месяце составляет 1 000 000 руб., и совсем другое, когда вы видите, что в начале года она была 2 000 000 руб., а затем плавно снижалась. Значит решения, которые вы принимаете по ее снижению, работают.

Какой смысл в значении дебиторской задолженности, если вы не знаете, какие клиенты и по каким сделкам ее сформировали? Значит, система должна позволять детализировать все цифры в различных разрезах.

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

Пример отчета о прибылях и убытках:

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

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

Важнейший момент — сквозной учет. Система должна позволять учитывать товар насквозь, по всем нужным вам параметрам. Что это означает? Это означает, что вы должны иметь возможность проследить историю любой отгрузки. Вы отгрузили товар клиенту, а система должна показать, из какой партии эта отгрузка, кто поставщик и где находятся остальные части партии. Без такой системы вы не получите правильного формирования счетов-фактур в разрезе грузовой таможенной декларации (ГТД), потому что если в отгрузке присутствует один и тот же товар, но из разных партий (товар закуплен у разных поставщиков), то в счете-фактуре товар должен быть разбит на разные строки, поскольку ГТД у них разная. Еще более сложный случай — учет серийных номеров изделий. Необходимость в нем возникает, когда компания занимается поставкой оборудования, которое необходимо обслуживать по гарантии, индивидуально по каждому изделию. Как вы можете быть уверены, что именно у вас было куплено это изделие? Только по серийному номеру.

Функции, которые должны быть в вашей ERP-системе

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

Документооборот. По сути, бизнес — это оборот денег, товаров и документов. Заказы, договоры, предложения, счета, накладные, акты, заявки и т.д. Все подобные документы система должна позволять делать не просто быстро, но и функционально. Одно дело, когда документ вы можете только распечатать, и совсем другое, когда вы можете его сохранить в различных форматах (pdf, doc, jpeg, xls и др) и отправить клиенту по электронной почте. Значит, система должна обладать современным встроенным редактором отчетов. Любой документ должен иметь маршрут, который он должен пройти в обязательном порядке (например, договор на поставку товара должен обязательно пройти юриста, проверка его грамотности и «подводных камней», коммерческого директора, и только после этого попасть к генеральному директору на подпись). Что очень важно, в процессе маршрута система должна по определенным правилам ограничивать доступ пользователей к документу или процессу (чтобы избежать утечки информации из компании, защититься от изменений после согласования), а сам маршрут документа должен быть гибко настраиваем.

Работа с клиентами. С ситуацией, когда у вашего клиента несколько юридических лиц, вы сталкиваетесь постоянно, а значит и сталкиваетесь с проблемой понимания взаиморасчетов по клиенту в целом. Сегодня ваш клиент купил у вас товар по одному своему юридическому лицу, а завтра по другому. Однако контролировать дебиторскую задолженность, объемы продаж, доход и т.д. вы хотите не по юридическим лицам ваших клиентов, а по клиенту в целом. Вы должны четко понимать по каждому клиенту, какую часть прибыли (и других показателей) сформировал по компании именно этот клиент (а не юридическое лицо клиента). И в абсолютном выражении, и в относительном.

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

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

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

– когда и какой договор заключен
– когда и какие выставлены счета клиенту
– когда и как они оплачены
– когда и у кого товар заказан
– когда и как оплачены счета поставщика
– когда, на какой склад, и по каким накладным вам поставили этот товар
– когда груз доставлен клиенту, по каким накладным, с какого склада.

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

Работа с поставщиками. Работа с поставщиками подразумевает под собой формирование заказов поставщикам, учет счетов поставщиков, накладных и других документов. Также система должна позволять фиксировать предложения поставщиков на ваши заказы (чтобы иметь возможность выбирать лучшего поставщика по различным параметрам). Однако такую возможность удобно использовать, когда речь идет о крупных спецификациях, а если ваш заказ состоит из нескольких наименований, то заносить в систему все предложения просто экономически нецелесообразно, поскольку эта задача тоже требует времени. При работе с поставщиками вы должны иметь возможность насквозь проследить каждую сделку от момента заказа до момента прихода товара на склад: когда товар заказан, какой счет (или счета) вам выставили в ответ на ваш заказ, когда и как его оплатили, по каким накладным и когда вам поставили груз. Система должна позволять фиксировать точки нахождения груза, если речь идет о длительных поставках. Ну и, конечно, контролировать все дополнительные затраты на поставку и включать их в себестоимость груза. Что касается планирования, то грамотный инструмент планирования поставок позволит существенно сократить складские запасы без потерь для объемов продаж, а значит — освободить оборотные средства, что в нынешней ситуации с кредитованием весьма актуально.

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

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

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

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

Читайте так же:  Уголовный кодекс ст 60

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

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

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

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

Планирование. Должна ли система позволять планировать деятельность компании? Несомненно. Однако большинству малых предприятий это не нужно, просто потому что сама система планирования — это тоже определенные затраты, которые не всегда окупятся. Но если не нужно сейчас, то может пригодиться позже. Поэтому ознакомьтесь с инструментами и возможностями планирования. Что касается финансового планирования, то система должна позволять планировать показатели деятельности не только в валовом эквиваленте, но и по подразделениям, сделкам, клиентам. Система контроля кассовых разрывов поможет предотвратить ситуации, когда деньги нужны, а их нет. Однако внедрить такую систему на предприятии не просто, т.к. придется планировать буквально каждый платеж, а это не всегда возможно. Что касается планирования поставок продукции (сырья), то этот вопрос на порядок сложнее финансового планирования, как с точки зрения требований, так и с точки зрения сложности внедрения. Я сейчас говорю не о системе заказа товаров, когда остатки достигли страховых запасов, а о реальном планировании, где алгоритмы планирования учитывают сроки поставки, транспорт, сезонность, текущие поставки и другие критерии. Думаю, не ошибусь, если скажу, что только одна из двадцати компаний, взявшихся за внедрение планирования поставок, доведет это до логического конца. Но стоит посмотреть на инструменты, которые есть в системе, и, желательно, поинтересоваться, по каким именно алгоритмам работает планирование, как конкретно обеспечивается планирование закупок по компании в целом и подвоз товаров на склады. Насколько эти алгоритмы подходят именно вашей компании, решать вам. Но повторюсь еще раз: внедрить в компании (особенно в компаниях с большим ассортиментом) полноценно работающее планирование закупок — это архисложная задача, которая, зачастую, решается годами.

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

Управление кадрами. Управление кадрами — это не просто список сотрудников, это и структура компании, ее штатное расписание, всевозможные приказы, отчеты, трудовые договоры и т.д. Ну и, конечно же, зарплата, алгоритмы которой часто принимают такие причудливые формы, что кажется, это вообще невозможно автоматизировать. Самым сложным в алгоритмах расчета зарплаты является расчет премий сотрудникам, и здесь система должна позволять настраивать автоматический расчет премий для различных сотрудников на основе различных финансовых показателей. Иными словами, одни сотрудники должны получать 10% от прибыли (или от выручки) по определенной группе товарных позиций при выполнении плана (или без плана), а другие 15%. Более сложные алгоритмы, видимо, придется дорабатывать индивидуально.

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

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

Как верно описать требования к ERP-системе?

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

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

  • Требования к функциональным характеристикам. Здесь прописываются требования к составу функций, выполняемых КИС и организации входных/выходных данных. В этом же разделе определяются основные объекты взаимодействия в системе.
  • Требования к составу и параметрам технических средств. В этом разделе должен быть описан состав технических средств, необходимых для нормальной работы КИС. Под техническими средствами здесь понимается совокупность аппаратного обеспечения и прочей сопутствующей инфраструктуры. Весь состав технических средств, указанный в этом разделе, должен приводиться с указанием их ключевых технических характеристик.
  • Требования к отказоустойчивости системы. Здесь указываются требования к обеспечению нормальной работы КИС, а также описывается организация ее системы безопасности. К примеру, именно в этом разделе оговариваются такие параметры, как максимальное время восстановления системы после программных, аппаратных или иного рода сбоев. Здесь же должны быть прописаны и механизмы восстановления КИС. Кроме того, в этом разделе указываются требования к контролю входной и выходной информации, применению криптосредств и многое другое.
  • Требования к программной совместимости. Здесь указываются требования к программным средствам, используемым КИС, к информационным структурам на входе и выходе в систему, а также методам интеграции КИС с необходимым унаследованным ПО.
  • Требования к возможности модернизации системы. В этом разделе должны быть предусмотрены возможности КИС «на будущее». Именно здесь описываются возможные изменения в структуре и методах управления компании, которые должны быть заложены в ERP-систему.
  • Требования к эксплуатации системы. Здесь указываются все необходимые эксплуатационные характеристики. Это могут быть как требования к техническому обслуживанию системы, например, регламентация резервного копирования, так и требования к квалификации сотрудников, выполняющих те или иные функции для обеспечения надежной работы КИС.

Эти 6 требований являются основными при описании требований к ERP-системе. Помимо них существуют и ряд других требований, зависящих как от специфики бизнеса, так и от уровня детализации технического задания. Например, иногда отдельно прописываются также требования к программной документации КИС. Кроме того, важно разделять подготовку технического задания при разработке системы на заказ и внедрении готовой КИС. В первом случае указанные выше требования предопределяют состав работ и их фактический объем, во втором же – некоторые из них, особенно в части технических характеристик, являются номинальными. Дело в том, что в случае выбора готового решения, кастомизация сводится практически полностью к доработке КИС под конкретные бизнес-процессы и не затрагивает технических характеристик системы, которые предопределены выбором конкретного решения.

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

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

  • Методология ARIS (Architecture of Integrated Information Systems), нотация eEPC, программное средство – ARIS Toolset. Применение этого варианта для описания требований очень хорошо подходит в случае построения модели процессов на основе проведения интервью. Кроме того, если внедрение КИС является лишь частью общего проекта по реорганизации деятельности предприятия, то использование ARIS Toolset оказывается предпочтительным за счет поддержки большого количества нотаций. Вместе с тем, простота нотации eEPC во многом достигается за счет отсутствия жесткий требований в ней, что, нередко бывает достаточно критично.
  • Методология SADT (Structured Analysis and Design Technique), нотации IDEF, программные средства – All Fusion Process Modeler (ранее BPWin) и Data Modeler (ранее ERWin). Нотации IDEF отличаются своей строгостью, за счет которой, в частности, обеспечивается высокое качество модельного описания.
  • UML (Unified Modeling Language), программные средства – Rational Rose или Visual Modeler. Данный подход применяется в основном при заказной разработке системы.

Опять же, в случае выбора конкретного решения (наиболее распространенный вариант), нотация и, соответственно, CASE-средства предопределены либо бизнес-логикой КИС, либо опытом использования данных нотации и CASE-средств с конкретной ERP-системой. Например, при внедрении mySAP ERP применяется нотация eEPC и ARIS Toolset. Кроме того, как видно из примера с ARIS, выбор нотации существенно зависит от методов проведения предпроектного консалтинга, а также целей и задач внедрения КИС в масштабе компании. Тем не менее, выбор конкретной нотации зависит от многих параметров и требует высокой квалификации специалиста.

Опубликовано в Без рубрики   
Sociologs.ru 2019 Все права защищены