Inf_comp_sys

обоснованного множества параметров, многовариантного анализа, оптимизации и прогнозирования - то есть комплексности системы.

1.4.1.2 Модульность

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

1.4.1.3 Открытость

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

1.4.1.4 Адаптивность

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

11

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

1.4.1.5 Надежность и доступность

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

1.4.1.6 Безопасность

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

1.4.1.7 Защита от потерь данных

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

1.4.1.8 Целостность и непротиворечивость данных

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

1.4.1.9 Предотвращение несанкционированного доступа

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

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

1.4.1.10Масштабируемость

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

12

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

1.4.1.11Мобильность

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

1.4.1.12Простота в изучении

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

1.4.1.13Поддержка и сопровождение

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

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

1.4.2Требования к среде функционирования КИС

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

13

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

1.5Этапы развития информационно-вычислительных систем

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

Готовые программные комплексы (ПК), предназначенные для внедрения в качестве базиса информационных систем, обладают одним общим характерным свойством: они сложны для оперативного ознакомления. Эта проблема обусловлена следующими факторами.

Сложность не только внутренних механизмов работы, но и наблюдаемой функциональной структуры.

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

14

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

Доступность материалов исключительно рекламного характера. Фактическое отсутствие описания реального опыта использования программного комплекса и истинной статистики внедрений.

1.6Примеры маркетинговых тезисов

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

1.6.1“Наша система отвечает требованиям ERP-стандарта (класса)”

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

1.6.2“Наша система отвечает требованиям стандарта MRPII”

В отличие от ERP, MRPII в некотором смысле является стандартом. Если выражаться точно, то MRPII (Manufactory Resource Planning) – это концепция управления производством и запасами, последняя её редакция (MRPII Standard System) была опубликована в 1989 г. американской ассоциацией управления производственными ресурсами APICS (http://www.apics.org). Концепция MRPII является методологией менеджмента и возможность её применения на крупных предприятиях стала реальностью с прогрессом в области информационных технологий. Принадлежность решения к классу MRPII должна означать функциональную поддержку программным обеспечением выполнения следующего цикла: “планирование заказов -> планирование потребности в сырье и материалах -> планирование производственных ресурсов -> контроль над исполнением производственной программы -> обратная связь”. Как показывает опыт, разработчики говорят о соответствии программного комплекса требованиям MRPII, когда существует какая-либо возможность планирования производственных ресурсов, а не только в тех случаях, когда поддерживается весь цикл. В первую очередь это касается отечественных компаний.

15

1.6.3 “Наша система является системой управления, а не системой учета”

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

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

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

1.6.4 “Наша система имеет многолетний опыт успешных внедрений на Западе и обладает самым большим набором отраслевых решений.”

Действительно, многие зарубежные программные комплексы имеют солидный и позитивный опыт применения на Западе. Однако не стоит забывать, что сами по себе подходы к управлению в нашей стране и на Западе существенно различаются. Например, в большинстве экономически развитых стран существуют и широко применяются на практике отраслевые стандарты менеджмента. Тем самым, западные тиражируемые ПК, как правило, подразумевают наличие общего стандартного регламента управления деятельностью предприятий, при этом, позволяя (благодаря широким возможностям по настройке) учитывать все индивидуальные особенности. То же самое можно отнести и к понятию “отраслевое решение”. Не секрет, в России (учитывая то, что соответствующий национальный менеджмент, как дисциплина, развивается чуть более 10 лет) практически не существует отраслевых управленческих стандартов (имеются в виду именно управленческие, а не технологические стандарты), и два предприятия, относящиеся к одной отрасли, могут принципиально различаться с точки зрения действующего управленческого регламента.

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

16

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

1.6.5 “Наша система разработана в России и наиболее всего подходит для автоматизации отечественных предприятий”

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

Низкий уровень функциональности, интегрированности и недостаточное количество настроек.

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

Нестабильность работы.

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

Отсутствие актуальной технической и пользовательской документации.

Несоблюдение принципа “версионности”.

Несоответствие маркетинговой информации реальным возможностям программного комплекса.

Финансовая нестабильность разработчика.

1.7Выбор из "готовых" информационно-вычислительных ситем

Сточки зрения стоимости, отечественные решения выглядят привлекательно, однако, как показывает опыт, большинству из них (несмотря на громкие рекламные заявления) под силу автоматизировать лишь только некоторые базовые учетные функции, например: бухгалтерию, кассу, склад и расчёты с контрагентами.

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

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

17

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

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

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

18

Глава 2. Системы класса MRP

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

2.1История происхождения систем MRP

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

Изначально MRP системы разрабатывались для использования на производственных предприятиях с дискретным типом производства, например:

Сборка на заказ (Assembly-To-Order, ATO)

Изготовление на заказ (Make-To-Order, MTO)

Изготовление на склад (Make-To-Stock, MTS)

Серийное (RPT).

Если предприятие имеет процессное производство (Process Industry, Continuous-Batch Processing), то применение MRP-методологии оправдано в случае длительного производственного цикла. «…MRP системы редко используются для планирования материальных потребностей в сервисных, транспортных, торговых и других организациях непроизводственного профиля, хотя потенциально идеи MRP-систем могут быть с некоторыми допущениями применены и для непроизводственных предприятий, деятельность которых требует планирования материалов в относительно длительном интервале времени…». MRP системы базируются на планировании материалов для оптимальной организации производства и включают непосредственно функциональность MRP, функциональность по описанию и планированию загрузки производственных мощностей CRP (Capacity Resources Planning) и имеют своей целью создание оптимальных условий для реализации производственного плана выпуска продукции.

19

2.2Структура MRP системы

2.2.1Терминология

2.2.1.1 Материалы

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

2.2.1.2 MRP-система

MRP-система, MRP-программа – программный комплекс или программа, работающая по MRP алгоритму.

2.2.1.3 Статус материала

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

материал есть в наличии на складе;

материал есть на складе, но зарезервирован для других целей;

материал присутствует в текущих заказах;

заказ на материал планируется.

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

2.2.1.4 Страховой запас

Страховой запас (safety stock) материала необходим для поддержания процесса производства в случае возникновения непредвиденных и неустранимых задержек в его поставках. По сути, в идеальном случае, если механизм поставок полагать безупречным, MRP-методология не постулирует обязательное наличие страхового запаса, и его объемы устанавливаются различными для каждого конкретного случая, в зависимости от сложившейся ситуации с поступлением материалов.

2.2.1.5 Потребность в материале

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

Чистая потребность = полная потребность – инвентаризовано на руках

– страховой запас – зарезервировано для других заказов

20