Бизнес правила ис это

Модель организационной структуры предприятия представ­ляет собой традиционную иерархическую структуру подчине­ния подразделений и персонала (организационных единиц). На­значение моделирования организационной структуры приме­нительно к информационной системе заключается в распреде­лении автоматизируемых функций по работникам подразделе­ний и определении полномочий доступа к информационной системе.

Бизнес-правила — это специальные сведения, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и про­цессов конфигурации и эксплуатации ИС. В системе R/3 биз­нес-правила встроены в бизнес-объекты, в системе BAAN биз­нес-правила выделены в самостоятельные компоненты.

Рассмотрим реализацию модельно-ориентированного проектиро­вания ИС.

В силу сложности комплексной типовой информационной системы для модельно-ориентированного проектирования харак­терны следующие особенности.

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

Как выйти из управленческого тупика. Правило эволюции бизнеса № 1.

• Консультанты со стороны фирмы-производителя программ­ного продукта принимают участие на всех этапах внедрения системы и особенно на этапе анализа требований.

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

В известных методологиях модельно-ориентированного про­ектирования ИС Accelerated SAP и BAAN Orgware большое внимание уделяется регламентации последовательности опера­ций на основе применения программных средств планирования, позволяющих ускорить процесс внедрения типовой ЭИС.

Техно­логия модельно-ориентированного проектирования ИС вклю­чает четыре основные стадии:

– выбор типового проекта,

– разра­ботка проектной модели предприятия,

– ввод в эксплуатацию и поддержка функционирования.

На всех стадиях используется инструментарий моделирова­ния предприятия.

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

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

3 правила Миллиардера | Игорь Рыбаков | Россия | Бизнес #Shorts

На стадии построения предварительной модели предприятия строятся модели:

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

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

На стадии «Разработка проектной модели предприятия» производится привязка модели предприятия к функционально­сти типовой ИС, на основе которой в последую­щем автоматически выполняется конфигурация информационной системы.

На стадии разработки проектной модели предприятия выпол­няются следующие работы:

• инсталляция программного продукта, реализующего типовую ИС;

• проведение обучения проектной команды;

• привязка модели предприятия к компонентам типовой инфор­мационной системы;

• определение требований к доработке программного обеспе­чения;

• проектирование внешних интерфейсов системы.

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

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

Далее производится » Привязка бизнес-объектов к программным мо­дулям «. В объектно-ориентированном представлении дан­ная операция выполняется путем задания имен методов в опре­делениях классов объектов. В функционально-ориентированном представлении для соответствующих процедур задается список входных и выходных объектов. Корректность привязки контро­лируется с помощью бизнес-правил.

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

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

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

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

Генерация пользовательских интерфейсов выполняется автоматически по модели взаимодействия исполнителей и программных модулей (опи­санию ролей пользователей).

Доработка программных модулей или разработка новых про­граммных модулей и интерфейсов осуществ­ляется на основе определенных ранее спецификаций на доработ­ку программных модулей и интерфейсов с использованием языковых средств типовой системы.

В завершении стадии реализации осуществляется комплекс­ное тестирование всех компонентов корпоративной ИС.

Стадия «Ввод в эксплуатацию» осуществляется по­этапно в соответствии с определенным планом. Перед началом эксплуатации должны быть выполнены следующие работы:

• создание документации конечных пользователей и их обучение;

• установка программно-технической среды эксплуатации ИС;

• наполнение информацией новых баз данных или подключе­ние и конвертация существующих баз данных.

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

Литература к разделу 2

1. Грекул В. И. Проектирование информационных систем / В. И. Грекул, Н. Г. Денищенко, Н. Л. Коровкина. – Интернет‑университет информационных технологий – ИНТУИТ.ру, 2005.

2. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф.
Проектирование экономических информационных систем. – М.: Финансы и статистика, 2002. – 512 с.

3. Павлов, А. Н. Опыт управления проектами на основе стандарта PMI PMBOK: изложение методологии и опыт применения. – М.: Бином. Лаборатория знаний, 2011. – 208 с.

4. Орлик, С. Программная инженерия //

5. SWEBOK // https://ru.wikipedia.org/wiki/SWEBOK

6. Guide to the Software Engineering Body of Knowledge: 2004 version Swebok. – Computer Society, 2004. – 202 p. (книга доступна для чтения по адресам: https://www.swebok.org и https://lib.mexmat.ru/books/11832. Переводы глав оригинального SWEBOK с замечаниями и комментариями доступны на сайте С. Орлика: https://swebok.sorlik.ru/index.html).

7. Дубова, Н. Знакомьтесь: SWEBOK // https://www.osp.ru/os/2006/07/3290839/

8. Рекомендации по преподаванию программной инженерии и информа­тики в университетах = Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering; Computing Curricula 2001: Computer Science. – М.: ИНТУИТ.РУ «Интернет‑университет информационных технологий», 2007. – 462 с.

9. Маглинец, Ю. А. Анализ требований к автоматизированным информа­цион­ным системам. – М.: Интернет‑университет информационных технологий, БИНОМ. Лаборатория знаний, 2008. – 200 с.

10. Вигерс, К. Разработка требований к программному обеспечению. – М.: Издательско-торговый дом «Русская Редакция», 2004. – 576 с.

11. Леффингуелл, Д., Уидриг, Д. Принципы работы с требованиями к программному обеспечению. – М.: Вильямс, 2002. – 448 с.

12. Коберн, А. Современные методы описания функциональных требований к системам. – М.: Лори, 2002. – 263 с.

13. Мацяшек, Л. Анализ и проектирование информационных систем с помощью UML 2.0. – М.: Вильямс, 2008. – 816 с.

14. Орлик, С., Булуй, Ю. Программные требования (Software Requirements по SWEBOK) // https://swebok.sorlik.ru/1_software_requirements.html

15. Бизнес-требования к информационной системе //

16. IEEE Standart 830‑1998. IEEE Recommended Practice for Software Requirements Specifications.

17. Спецификация программного обеспечения //

18. Методика составления спецификаций требований к программному обеспечению (IEEE-830-1998) //

19. Халл, Э., Джексон, К., Дик, Дж. Разработка и управление требова­ниями. – М.: Telelogic, 2005. – 230 с.

20. Золотухина, Е. Б. Управление требованиями при разработке програм­мных систем с использованием Rational RequisitePro. – М.: ИНТЕРФЕЙС, 2002. – 81 с.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Бизнес-правило

A Бизнес-правило определяет или ограничивает некоторые аспекты бизнеса и всегда принимает значение true или false. В нем конкретно указаны термины, факты и правила. Бизнес-правила предназначены для утверждения структуры бизнеса или для контроля или влияния на поведение бизнеса. Бизнес-правила описывают операции, определения и ограничения, которые применяются к организации.

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

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

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

Введение

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

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

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

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

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

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

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

Типы бизнес-правил

При попытке определить типы бизнес-правил следует помнить о нескольких утверждениях:

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

Принимая во внимание эти утверждения, бизнес-правила можно разделить на один из трех типов:

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

Категории

Согласно официальному документу Business Rules Group, формулировка бизнес-правила попадает в одну из четырех категорий:

• Определения бизнес-терминов

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

• Факты, связывающие термины друг с другом

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

• Ограничения (также называемые «утверждениями действий»)

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

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

Реальные приложения и препятствия

Бизнес-правила собираются в следующих ситуациях:

1. Когда это диктуется законом
2. Во время бизнес-анализа
3. Как бесполезнаяпомощь инженерам.

Такое отсутствие единообразия в основном связано с затратами и усилиями, необходимыми для поддержания списка правил.

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

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

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

Формальная спецификация

Бизнес-правила, закодированные в компьютерном коде в операционной программе, известны как бизнес-логика.

Подобно тому, как бизнес-риски могут быть структурированы как:

Если Тогда

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

Когда Тогда В противном случае

См. Также

• Бизнес-процесс
• Подход бизнес-правил
• Управление бизнес-правилами система
• Business ru le Engine
• Слюни

Ссылки

• УОКЕР, Адриан; и другие. (1990). Системы знаний и пролог. Эддисон-Уэсли. ISBN 0-201-52424-4.
• ФОН ХАЛЛЕ, Барбара и ГОЛДБЕРГ, Ларри (9 октября 2006 г.). Революция правил бизнеса. Рад за. ISBN 1-60005-013-1.
• ФОН ХАЛЛЕ, Барбара (2001). Применяются бизнес-правила. Вайли. ISBN 0-471-41293-7.
• МОРГАН, Тони (2002). Бизнес-правила и информационные системы: согласование ИТ с бизнес-целями. Эддисон-Уэсли. ISBN 0-201-74391-4.
• Принципы подхода к бизнес-правилам, Рональд Г. Росс (Aw Professional, 2003) ISBN 0 -201-78893-4
• Управление бизнес-процессами с использованием бизнес-правил, Том Дебевуаз (Business Knowledge Architects, 2005) ISBN 0-9769048-0-2

Внешние ссылки

• Итоговый документ семинара: Шесть взглядов на систему управления бизнес-правилами
• Группа бизнес-правил

Источник: alphapedia.ru

Проектирование управленческой информационной системы ERP-класса

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

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

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

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

1. Сбор первичных данных о деятельности предприятия и представление их в удобном для анализа виде

2. Управленческий и регламентированный учёт

3. Поддержка документооборота

4. Планирование и прогнозирование

5. Поддержка бизнес-процессов

В начале 2000-х годов автор работал в оптово-розничной компании, использовавшей систему учёта товарно-материальных ценностей собственной разработки. К тому моменту в системе насчитывалось более 700 отчётов, в которых рассчитывались несколько десятков тысяч показателей. Поскольку практики описаний отчётов не было и разобраться в этом хаосе не представлялось возможным, каждый новый менеджер заказывал себе 10-15 новых отчётов, мобилизуя на эту работу программистов всеми доступными методами. Знакомая картина непозволительного расходования ресурсов?
Возникает вопрос: как на этапе проектирования ИС составить необходимый и достаточный список показателей, которые затем будут представлены в отчётах, предназначенных для принятия управленческих решений? Поскольку мы определились с тем, что ИС ERP должна стать инструментом СУ, ответ на этот вопрос очевиден: в ИС должны, в первую очередь, рассчитываться показатели, которые используются в СУ для управления деятельностью предприятия, подразделений, сотрудников. Показатели стратегического уровня управления разрабатываются на основе методики Balanced Scorecard (BSC), предназначенной для реализации стратегии предприятия. Таким образом, реализуя в ИС систему показателей BSC, мы обеспечиваем интеграцию ИС ERP и СУ на уровне стратегии. Подчинённые показатели выстраиваются методом декомпозиции стратегических показателей и составляют основу план-фактного управления предприятием.
Для решения задачи ИС, перечисленной в списке под номером 1, системы показателей недостаточно. Необходимо также предусмотреть сбор первичных данных, на основе которых эти показатели будут рассчитываться.

Решения о том кто, когда, по какому событию, при каких условиях регистрирует эти данные в информационной системе, должны быть зафиксированы в документах проекта ИС ERP: ролях пользователей, описаниях бизнес-процессов, регламентах бизнес-процессов, требованиях к функционалу. Не является также излишней проработка форматов отчётов, в которых показатели будут представлены. Если этот вопрос будет отдан на откуп программисту, заказчик может быть неприятно удивлён результатом в тот момент, когда обязательства внедренцев по этому вопросу будут уже выполнены. Активное участие заказчика в определении форматов является залогом получения результата в действительно «удобном для анализа виде».
Для того, чтобы система управления по показателям стала эффективным инструментом СУ, она должна быть проработана на процедурном уровне. Поэтому процедуры планирования показателей, сбора исходных данных, план-фактного анализа должны быть формализованы на этапе разработки бизнес-процессов предприятия.
Вообще говоря, задача ИС ERP, обозначенная выше под номером 2, является частным случаем задачи N 1. Управленческий и регламентированный учёт – это также процессы сбора первичных данных и представления информации для анализа сотрудниками компании и налоговыми органами, соответственно. Однако, на этапе управленческого консалтинга вопросы учёта необходимо рассмотреть отдельно, так как они должны найти специфическое отражение в проекте ИС.
В первую очередь, это касается описания юридической структуры предприятия и соответствующего документооборота. Зачастую, даже небольшие российские компании представляют из себя своего рода холдинги, объединяющие несколько юридических лиц, связанных коммерческими отношениями. Задача ИС заключается в формировании регламентной отчётности юридических лиц и управленческой отчётности холдинга с требуемой детализацией. В современных ИС класса ERP имеются развитые средства реализации юридических структур холдингов, но для настройки этих средств, структура и документооборот должны быть проанализированы и описаны на этапе формирования проекта. Таким образом будет достигнута интеграция ИС с организационной-правовым уровнем СУ предприятием.
Другой вопрос учёта, который должен быть проработан на этапе разработки проекта ИС — это учётная политика. Если учётная политика регламентированного учёта определяется действующим законодательством, то управленческая учётная политика разрабатывается самим предприятием и должна соответствовать его целям, стратегии, структуре управления. Управленческая учётная политика фиксируется в документе общепринятой структуры и является составной частью проекта ИС ERP.
В процессе проектирования будущей системы учёта должны быть также проработаны требования по безопасности и защите учётной информации.
Наконец, для обеспечения преемственности новой системы учёта с уже накопленной информацией, должны быть проработаны вопросы переноса справочников, остатков ТМЦ и денег, документов в новую ИС. Фактически, речь идёт об обеспечении непрерывности информационной поддержки системы управления предприятием.
Для обеспечения решения третьей из перечисленных задач ИС ERP, а именно поддержки документооборота, на этапе проектирования управленческой ИС должен быть проанализирован и структурирован документооборот компании. Обычно выделяют следующие подсистемы документооборота:
• Поддержка Юридической структуры
• Движение ТМЦ
• Обмен сообщениями, документами
• Формирование планов, задач. Отчётность по ним
• Создание, согласование, утверждение документов
• Регистрация и контроль исполнения входящих и исходящих
• Организация архива документов
В ходе проектирования управленческой ИС принимается решение о том, какие подсистемы документооборота будут поддерживаться ИС и формируется их описание, которое должно найти своё отражение в документах проекта информационной системы: графическом отображении бизнес-процессов, форматах структур данных, отчётах ИС, ролях пользователей, печатных формах. Таким образом, на этом этапе закладываются основы документарной поддержки СУ.
Учёт фактических данных в той или иной форме ведётся в компании всегда. А вот возможность полноценного решения четвёртой задачи ИС – планирования и прогнозирования, появляется только с момента внедрения ИС.
Планирование, как система целеполагания, является неотъемлемой частью системы управления предприятием. В ходе работ над проектом ИС ERP определяются состав планов, горизонты и периоды планирования, бизнес-процесс и средства ввода плановых значений, форматы план-фактных отчётов, бизнес-процессы план-фактного анализа и коррекции планов. Перечень планируемых показателей определяется списком, сформированным в ходе проектирования системы показателей. Особого внимания заслуживает система бюджетирования, которая является основой системы управления финансами. На этапе управленческого консалтинга проектирования ИС разрабатывается регламент бюджетирования, который включает в себя
• Описание финансовой структуры
• Форматы бюджетов
• Учётную политику
• Бизнес-процессы и правила их исполнения
Если планирование – это способ постановки целей, то прогнозирование – это формирование наиболее вероятного сценария развития событий на основе ранее собранной объективной информации. Современные ИС ERP-класса предоставляют широкие возможности для финансового прогнозирования, предназначенного для своевременного принятия эффективных решений в области оперативного управления финансами. В некоторых ИС реализован механизм номенклатурного прогнозирования продаж в натуральных единицах, что позволяет оптимизировать складские запасы и логистические ресурсы. На этапе проектирования ИС определяется состав прогнозов, которые будут использоваться менеджерами предприятия, их настойки, бизнес-процессы и регламенты применения. Таким образом, возможности ИС ERP по прогнозированию интегрируются в СУ.

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

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

Рис. 1. Общая процедура Управленческого консалтинга

Процедура этапа управленческого консалтинга проектирования ИС ERP начинается с диагностики системы управления предприятием , которая проводится в следующей последовательности:
1. Ознакомление с материалами компании
2. Совещание с руководителем компании, на котором уточняются
• направления деятельности компании (продукты, рынки сбыта)
• состояние системы управления
• список ведущих сотрудников, зоны ответственности
• существующие проблемы
• график интервью с ведущими сотрудниками компании
3. Интервью с ведущими сотрудниками
5. Анализ существующих документов системы управления
6. Подготовка предложений по развитию системы управления
7. Подготовка предложений по плану работы
После согласования плана работы с заказчиком, разрабатывается функциональный проект ИС, ссылка на пример в конце статьи.
В процессе настроек ИС и доработок типового функционала консультант взаимодействует с внедренцами по вопросам формирования постановок задач и технических заданий, а в процессе обучения пользователей и внедрения ИС ERP в опытную эксплуатацию консультирует пользователей по вопросам, находящимся в его компетенции. Таким образом, работа консультанта начинается на самом раннем этапе проектирования информационной системы и заканчивается только после внедрения управленческой ИС.

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

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

Как заказать наши услуги

УЗНАТЬ ПОДРОБНЕЕ

1. Наши услуги
2. Сколько стоит консалтинг?
3. Примеры работ
4. Отзывы клиентов
5. Подписка на рассылку

Источник: piter-consult.ru