Файл: PRIS.doc

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

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

Такова роль ERP-системы в идеале. Реальность несколько жестче. Вернемся к тем же папкам для бумаг. Этот процесс может быть и не эффективен, но зато он прост и привычен. Бухгалтерия делает свою работу, склад – свою, и если что-нибудь за стенами отдела не так, это - чужая проблема. C приходом ERP всё меняется: продавец больше не является машинисткой, всего лишь набирающей имя клиента и нажимающей клавишу “Enter”. Экран ERP-системы превращает его в бизнесмена. Продавец переходит от кредитной истории клиента к ситуации на складе. Заплатит ли клиент вовремя? Сможем ли мы вовремя отгрузить? Таких решений продавцы никогда раньше не принимали, а от этих решений зависят клиенты, и зависят другие подразделения компании. И не одним только продавцам приходится проснуться – народ на складе, который раньше держал весь список товаров в голове или на клочках бумаги, теперь должен вводить его в компьютер. Если они не будут делать это регулярно и быстро, продавец скажет клиенту, что товара нет на складе, клиент отправится к другому поставщику, и компания потеряет деньги.

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

Использование систем MRP позволило компаниям достичь следующих результатов:

- снизить уровень запасов сырья и материалов на складах - снизить уровень запасов в незавершенном производстве - повысить эффективность производственного цикла - сократить сроки выполнения заказов

Несмотря на высокую эффективность систем MRP в них был один существенный недостаток, а именно, они не учитывали в своей работе производственные мощности предприятия. Это привело к расширению функциональности MRP систем модулем планирования потребностей в мощностях (CRP - Capacity Requirements Planning). Связь между CRP и MPS позволяла учитывать наличие необходимых мощностей для производства определенного количества готовых изделий. Системы MRP имеющие в своем составе модуль CRP стали называться системами планирования потребностей в материалах замкнутого цикла (Closed Loop MRP).

В 80х годах появился новый класс систем - системы планирования производственных ресурсов предприятия (Manufacturing Resource Planning). Из-за схожести аббревиатур такие системы стали называть MRPII.

Основное отличие MRPII от MRP, заключается в том, что системы MRPII предназначены для планирования всех ресурсов предприятия (включая финансовые и кадровые).

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

Потребность в автоматизации управленческих процессов впервые была осознана в конце 60-х – начале 70-х годов, когда стало ясно, что управление крупной корпорацией подчиняется тем же законам, что и любая бюрократическая структура. Один из законов Паркинсона гласит: “штат организации никак не связан с объемом выполняемой ею работы”. Иными словами, с ростом численности управленческого персонала КПД его работы падает до нуля.

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

10. Типовое проектирование ИС. Внедрение ERP-систем. План Уайта. [8]

Понятия типового проектирования

Типовое проектирование ИС предполагает создание системы из готовых типовых элементов.

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

В соответствии с ГОСТ 24.103-84 выделяют 7 видов обеспечивающих подсистем:

• информационное,

• программное,

• техническое,

• организационное,

• метрологическое,

• правовое,

• лингвистическое.

Примерами функциональных подсистем могут быть: кадры, финансы, производство, логистика…

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.

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

Важным принципом создания ТПР является то, что разработку ТПР осуществляют на основе использования проектных решений, реализованных в конкретных АСУ

Виды ТПР

По числу охватываемых видов обеспечивающих подсистем все ТПР делятся на две категории (Error: Reference source not found):

• простые;

• комбинированные.

Параметрически-ориентированное проектирование включает следующие этапы (Error: Reference source not found): определение критериев оценки пригодности пакетов прикладных программ (ПО) для решения поставленных задач, анализ и оценка доступных ПО по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ПО.

Критерии оценки ПО делятся на следующие группы:

• назначение и возможности пакета;

• отличительные признаки и свойства пакета;

• требования к техническим и программным средствам;

• документация пакета;

• факторы финансового порядка;

• особенности установки пакета;

• особенности эксплуатации пакета;

• помощь поставщика по внедрению и поддержанию пакета;

• оценка качества пакета и опыт его использования;

• перспективы развития пакета.

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

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

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

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

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

Нулевой цикл

Нулевой цикл состоит из следующих этапов:

1. Предварительное обследование и оценка состояния – это так называемое «предпроектное обследование».

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

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

На основе исследований строятся модели «as is» («как есть») и «to be» («как должно быть»).

2. Предварительная переподготовка.

Цель работ по предварительной переподготовке – объяснить высшему руководству, что представляет собой процесс внедрения ИС. На данном этапе важно преодолеть различия в понимании проекта разными категориями сотрудников. Руководители должны прийти к единому видению результатов и необходимых ресурсов. К сожалению, значение этого этапа часто недооценивается консалтинговыми и ИТ-компаниями, что создает ряд сложнейших проблем в дальнейшем.

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

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

• во-вторых, что самое сложное, с чем приходится сталкиваться в проектах создания ИС – человеческий фактор.

3. Техническое задание (ТЗ).

Техническое задание – набор документов и спецификаций, определяющих требования к информационной системе и ее функциональности. В него входят (Error: Reference source not found):

• требования к автоматизированным рабочим местам, их составу и структуре;

• разработка требований к программным средствам;

• разработка топологии, состава и структуры локальной вычислительной сети;

• требования к секретности и защите информации.

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

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

4. Технико-экономическое обоснование (ТЭО).

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

При проведении ТЭО надо помнить, что в большинстве случаев, дать обоснованную оценку возврата инвестиций в проект ИС не представляется возможным, так как «Ущерб от несвоевременных действий вследствие недостатка информации (как и прибыль - в обратном случае) расчету практически не поддается…».

5. Организация проекта.

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

Важно помнить, что ТОЛЬКО СОВМЕСТНАЯ работа заказчика и разработчика (с равной ответственностью за результат) позволят создать работоспособную ИС.

Оптимальная структура рабочей команды представляет собой сочетание и взаимодействие сотрудников автоматизируемого подразделения и консультантов исполнителя. Привлечение сотрудников объекта автоматизации – необходимый шаг. От него во многом зависит успех автоматизации, так как только эти сотрудники понимают существующие процессы и способны обоснованно обсуждать подходы к их улучшению. Кроме того, освоить систему можно, только принимая непосредственное участие в ее разработке или настройке. Пример схемы управления проектом приведен на схеме (Error: Reference source not found).