Требования к erp

Требования к erp

Откуда: Moscow
Сообщений: 1060

Я много раз встречался со спорами, что считать ERP-системой? Действительно, вопрос непростой: есть различные определиня, и информация на русском языке носит довольно разрозненный характер.

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

  • erp.lanit.ru — ряд неплохих статей
  • определения Gartner Group и APICS (American Production and Inventory Control Society)

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

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

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

    Противоречивые требования к ERP. Как согласовать?

    советник по ИТ — Алькор и Ко (розничная сеть Л’Этуаль)

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

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

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

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

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

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

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

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

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

    Варианты решения проблемы

    Можно усложнять алгоритмы учёта, теряя полноту и оперативность данных, что ведет к снижению точности и эффективности бизнес-решений (загрубление оценки стоимости стоков, неправильное ценообразование). Либо попытаться разделить разноплановые бизнес-процессы путем введения в архитектуру 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, выбор нотации существенно зависит от методов проведения предпроектного консалтинга, а также целей и задач внедрения КИС в масштабе компании. Тем не менее, выбор конкретной нотации зависит от многих параметров и требует высокой квалификации специалиста.

    ERP система NERPA – планирование ресурсов предприятия

    ERP система NERPA – это решение, предназначенное для планирования ресурсов предприятия. Программа ERP имеет модульную архитектуру и управляется через Web-интерфейс.

    Решение NERPA — это модульная ERP система управления ресурсами предприятия. Система использует локальный сервер предприятия или облачное решение для хранения и обработки данных, предоставляя пользователям Web-интерфейс для компьютеров и мобильных устройств.

    Ключевые возможности системы NERPA как программы ERP

    Системная интеграция всех процессов и структур в единое ERP решение

    ⇒ Основная задача ERP решения NERPA – это автоматизация как можно большего числа работ, связанных с планированием ресурсов. В состав ERP решения входят такие модули, как:

    Модуль управления активами предприятия, работами по техническому обслуживанию и ремонту оборудования.

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

    Отслеживание поставок, контакты с поставщиками, управление цепями поставок на предприятии.

    ECM — Документооборот

    Система электронного документооборота и обеспечения актуальной документацией других модулей NERPA.

    Управление персоналом предприятия и автоматизация работы сотрудников отдела кадров.

    Финансовый модуль программы ERP позволяет управлять финансами, платежами, счетами, бухгалтерскими отчётами

    Модуль для автоматизации управления складскими операциями и учёта запасов на предприятии.

    Модуль построения отчетов, аналитики в рамках планирования ресурсов предприятия.

    Модульная архитектура и облачные решения: быстрое внедрение ERP системы

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

    Web-интерфейс для компьютеров и мобильных устройств

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

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

    Многоязычная реализация ERP

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

    Ролевая модель доступа: удобство для пользователей, безопасность для данных

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

    Преимущества управления предприятием с программой NERPA

    Исходя из вышеописанных ключевых особенностей и преимуществ, архитектура и реализация программы NERPA предоставляют следующие удобные возможности для предприятий:

    • Минимальные требования к оборудованию для программы ERP (в особенности для «облачной» версии).
    • Высокая эффективность и безопасность, за счёт ролевой модели доступа к данным для отдельных сотрудников.
    • Управляемая конфигурация модулей системы для решения конкретных задач по автоматизации деятельности предприятия.
    • Пользователи могут управлять настройкой параметров данного ERP решения в очень широких пределах.

    Закажите демонстрацию работы NERPA и наши специалисты с радостью расскажут вам обо всех возможностях системы планирования ресурсов предприятия.

    Требования к оборудованию для ERP системы NERPA

    Основным техническим требованием системы NERPA является наличие достаточно быстрого и стабильного соединения по локальной сети. Для «облачной» архитектуры необходимо также соединение по сети Интернет (для Web- интерфейса пользователей). Остальные системные требования программы несущественны.

    Читайте так же:  Сис требования ассасин крид

    Внимание! Для конкретных предприятий требования к оборудованию могут немного отличаться; это зависит от таких особенностей, как набор используемых модулей ERP, количество сотрудников, работающих с программой, и количество записей в базах данных системы!

    Информационные системы планирования ресурсов и управления предприятием: ERP-сиcтемы

    Основные принципы выбора ERP-системы

    При выборе ERP -системы необходимо обратить особое внимание на следующие основные моменты.

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

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

    Гибкость и открытость. Это является одним из важнейших факторов выбора ERP -системы. В соответствии с мировым опытом, срок полнофункционального внедрения ERP -системы обычно длится не менее 3 лет, а полноценно работать она должна не менее 10 лет. За это время предприятие значительно меняется (его продукция, организационно-штатная структура, система управления, бизнес-процессы, роли и полномочия должностных лиц и др.). Информационно-аналитическая система, являющаяся основой управления предприятием, должна меняться вместе с производством. Она должна позволять легко менять АРМы и меню, формировать отчеты и справки, делать произвольные выборки информации в удобном представлении, менять технологию сопровождения бизнес-процессов и шаблоны отчетных форм путем параметрической настройки. Система должна легко настраиваться и интегрироваться в рамках ИИС предприятия с другим программным обеспечением (например, с корпоративным ПО расчета зарплаты или управления персоналом , ПО управления документооборотом, CAD / CAM / CAE -системами, PDM-системами и др.). Важным моментом при этом является то, что все необходимые доработки системы должна делать фирма-разработчик, юридически отвечающая перед предприятием за качество своей работы.

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

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

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

    Как правильно выбирать 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» ни на этапе выбора системы, ни при ее внедрении. Лучшим решением будет построение функциональной модели компании и определение требований к существующим в ней функциям. При создании модели обязательно используйте графические средства — это значительно облегчит работу с ней.

    Читайте так же:  30 подоходный налог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Другие статьи:

    • Развод ало это брат Развод ало это брат Playing track is prohibited in this country ( ) by request of the copyright holders. Прослушивание трека в этой стране ( ) запрещено по требованию правообладателей. Playing and downloading tracks from zaycev.net is prohibited in this country […]
    • Нотариус юзао воскресенье НОТАРИУС В СУББОТУ Многие работающие люди не могут посетить нотариальную контору в будние дни. Оптимальное решение – обращение за нотариальными услугами в субботу и воскресенье. Поэтому услуга нотариус без выходных ЮЗАО весьма востребована многими гражданами и […]
    • Пособие по усыновлению в сша Усыновление по-американски: мифы и реальность Принятие обеими палатами российского Федерального собрания «закона Димы Яковлева», запрещающего усыновление российских детей приемными родителями из США, вызвало большой шум в среде «заинтересованных лиц» , а это […]
    • Гаи развод харьков Развод "на пьянку". Как быть, если ГАИ обвиняет в нетрезвом вождении Вам понравился материал? Поделитесь с друзьями! Новогодние праздники уже на носу. В этот период многие хоть немножко, но выпивают. И в ГАИ об этом прекрасно знают. Что делать, […]
    • Лицензия на сми стоимость Стоимость лицензий Расчёт стоимости Чтобы предложить вашей компании все возможные решения, а также сделать ориентировочную бюджетную оценку импортозамещающего проекта, специалистам ALP Group необходимо проанализировать текущую архитектуру ее ИТ-сервисов. Анализ […]
    • Страховка ассистанс что это «Mondial Assistance Group» Купить страховку «Mondial Assistance Group» Ассистанская компания «Mondial Assistance Group» сама не продает страховые полисы. Она работает через страховые компании «Allianz» и «Абсолют страхование», где вы и можете купить страховку […]
    • Налог на транспорт в казахстане 2019 год таблица Налог на транспорт в 2019 году. Оплата налога онлайн Самостоятельный расчет транспортного налога на 2019 год можно произвести с помощью онлайн сервиса Комитета Государственных Доходов МФ РК по адресу kgd.gov.kz/ru/calc/transports. Оплатить налог за автотранспорт […]