лекция №1 - Научная библиотека НИЯУ МИФИ
advertisement
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ МОСКОВСКИЙ ИНЖЕНЕРНО-ФИЗИЧЕСКИЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ) Экономико-аналитический институт МИФИ КАФЕДРА ЭКОНОМИЧЕСКОЙ ДИНАМИКИ Специальность: 351400 прикладная информатика в экономике КУРС ЛЕКЦИЙ ПО КУРСУ «ПРОЕКТИРОВАНИЕ ИС» Москва 2007 1 ОГЛАВЛЕНИЕ ЛЕКЦИЯ №1 2 ТЕМА: Роль и место бизнес-процессов на современном предприятии. ЖЦ внедрения ИС. Методы моделирования бизнес-процессов. CASE-средства 3 ЛЕКЦИЯ №2 - 3 14 ТЕМА: Принципы структурного анализа. Базовые структурные методологии (SADT) и методология нотации (DFD, ERD). CASE-средства, поддерживающие структурный подход к проектированию ИС (AllFussion Process Modeler). 14 ЛЕКЦИЯ №4-5 23 ТЕМА: Принципы процессного анализа. Базовые процессные методологии (ARIS) и нотации (модели Organization chart, Function tree, EPC, ERD). CASE-средства, поддерживающие процессный подход к проектированию ИС (ARIS). Методология и нотация ARIS. 23 ЛЕКЦИЯ №6 41 ТЕМА: Основные подходы к реорганизации бизнес-процессов: 41 принципы Э. Деминга, японская парадигма улучшения бизнес-процессов (TQM, 6сигм), BPR (принципы Хаммера/Чампи). 41 ЛЕКЦИЯ №7 45 ТЕМА: Сравнительный анализ подходов к проектированию ИС. 45 ЛЕКЦИЯ №8 55 ТЕМА: Бизнес-процессы и информационные технологии: классификация информационных систем, современные подходы к построению корпоративной информационной системы (КИС) (обзор рынка систем, основной функционал, факторы риска при внедрении систем класса ERP, критерии выбора ERP). 55 ЛЕКЦИЯ №9 75 ТЕМА: Обзор ERP-систем «крупного» класса. Обзор рынка систем. Основной функционал систем, на примере системы SAP R3 75 ЛЕКЦИЯ №10 84 ТЕМА: Обзор ERP-систем «среднего» класса. Обзор рынка систем. Основной функционал систем, на примере системы Microsoft DynamicsAx. 84 ЛЕКЦИЯ №11 94 ТЕМА: Обзор ERP-систем «малого» класса. Обзор рынка систем. Основной функционал систем, на примере системы 1С или БОСС 94 ЛЕКЦИЯ №12 98 ТЕМА: Сравнительный анализ ERP-систем 98 Список литературы Error! Bookmark not defined. Приложение. Сравнительный анализ ERP-систем с точки зрения внедрения 116 ЛЕКЦИЯ №1 2 ТЕМА: Роль и место бизнес-процессов на современном предприятии. ЖЦ внедрения ИС. Методы моделирования бизнес-процессов. CASEсредства Роль и место бизнес-процессов на современном предприятии Процессы: определения, характеристики, свойства Существует множество определений бизнес-процессов. Рассмотрим ключевые определения бизнес-процесса: 1. Совокупность различных видов деятельности, в рамках которой "на входе" используются один или более видов ресурсов, и в результате этой деятельности на "выходе" создается продукт, представляющий ценность для потребителя (Хаммер, Чампи, 1993). 2. Набор логически взаимосвязанных действий, выполняемых для достижения определенного выхода бизнес-деятельности (Davenport, Short, 1990). 3. Структурированное конечное множество действий, спроектированных для производства специфической услуги (продукта) для конкретного потребителя или рынка. Или - специфически упорядоченная совокупность работ, заданий во времени и в пространстве, с указанием начала и конца точным определением входов и выходов. Или – структурируемый, измеряемый набор действий, созданный, чтобы произвести определенный выход для конкретного клиента или рынка (Davenport, 1993). 4. Сущность, определяемая через точки входа и выхода, интерфейсы и организационные устройства, частично включающие устройства потребителя услуг\товаров, в которой происходит наращивание стоимости производимой услуги\товара (Porter, Millar,1985). 5. Множество внутренних шагов (видов) деятельности, начинающихся с одного и более входов и заканчивающихся созданием продукции, необходимой клиенту (просто клиент или процесс, протекающий во внешнем окружении компании) и удовлетворяющей его по стоимости, долговечности, сервису и качеству. Или – полный поток событий в системе, описывающий, как клиент начинает, ведет и завершает использование бизнеса (Ойхман, Попов, 1997). 6. Логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как продукт или услуга (Зиндер, 1996). 7. Горизонтальная иерархия внутренних и зависимых между собой функциональных действий, конечной целью которых является выпуск продукции или отдельных ее компонентов. (Верников, 1999) 8. Любые виды деятельности в работе организации (Deming, 1982). 9. Систематизированное последовательное исполнение функциональных операций, которые приносят специфический результат (TeleManagement forum). 10. Совокупность взаимосвязанных ресурсов и деятельности, которая преобразует входящие элементы в выходящие (Госстандарт, 1997). 11. Множество взаимосвязанных и взаимодействующих операций, которые преобразуют входы в выходы (ISO, 2000). 12. Ряд взаимосвязанных видов деятельности, преобразующих входы в выходы (ISO/IEC, 2001). 13. Действие, переводящее вход системного объекта в выход (Никаноров, 1969). 3 14. Процесс – последовательность действий, которые создают дополнительные ценности путем преобразования с помощью ресурсов входящих элементов в требуемые выходящие. («European Quality» №2, том 6, 1999 г., стр. 24-25). Проанализировав данные определения, дадим совокупное определение бизнеспроцесса: Бизнес-процесс – это совокупность взаимосвязанных и взаимодействующих видов деятельности (работ), преобразующих входы в выходные результаты, которые имеют ценность для конкретного потребителя. Рассмотрим структуру любого бизнес-процесса (Рис.1): П р оц е с с Владелец процесса Участники процесса Входная продукция Выходная продукция Последовательность выполняемых функций Материальные ресурсы Данные Документы Технические ресурсы Рис.1 Структура бизнес-процесса Для анализа Рис.1 введем базовые понятия: Вход бизнес-процесса - объект бизнес-процесса (процедура, операция), взаимодействующий с внешними бизнес-процессам и получающая от них информацию/материальные ресурсы Выход бизнес-процесса - объект бизнес-процесса (процедура, операция), взаимодействующий с внешними бизнес-процессам и передающая им информацию/материальные ресурсы, являющиеся результатом выполнения бизнеспроцесса Операция (работа) – часть бизнес-процесса. Декомпозиция бизнес-процесса - детальное описание бизнес-процесса, осуществляемое путем разбиения процесса на несколько частей и последующего их описания при помощи более подробных моделей Регламент бизнес-процесса – документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям. Завершающее событие - объект модели бизнес-процесса, отражающий факт завершения процедуры (функции) и полученный при этом результат Инициирующее событие - объект модели бизнес-процесса, отражающий событие, являющееся управляющим воздействием, необходимым для начала выполнения процедуры (функции) 4 Ресурсы – информация (документы, файлы), финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнес-процесса Показатели бизнес-процесса – количественные и/или качественные параметры, характеризующие бизнес-процесс и его результат. Владелец бизнес-процесса – должностное лицо, управляющее ходом бизнеспроцесса, несущее ответственность за результаты и эффективность бизнеспроцесса и имеющее в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-процессе . Поставщик - субъект, предоставляющий ресурсы. Потребитель (клиент) – субъект, получающий результат бизнес-процесса. Потребитель может быть: а) внутренний – то есть находящийся в организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес-процесса; б) внешний – то есть находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации. Отличительными чертами любого бизнес-процесса являются: Хозяин Процесса – должностное лицо, несущее ответственность за ход и результаты Процесса; Ресурсы – ресурсы, выделенные в распоряжение Хозяина Процесса для его проведения (оборудование, персонал, помещения, среду, транспорт, связь, материалы, финансы, документация и т. д.); Параметры Процесса – характеристики, по которым Хозяин Процесса и высший руководитель могут судить о том, насколько эффективно выполняется Процесс и достигаются ли запланированные результаты; Потребитель – потребитель результатов Процесса, степень удовлетворенности которого, также предназначена для оценки эффективности Процесса; Входы Процесса – входные объекты (сырье, продукция, комплектация, информация или услуга), которые преобразуются в Выходы Процесса, в ходе выполнения Процесса. Часто Входы одного Процесса являются выходами другого; Выходы Процесса – продукция, информация или услуга ради которой существует Процесс. Любой процесс обладает следующими отличительными характеристиками: Результативность – характеризует соответствие результатов процесса нуждам и ожиданиям потребителей Управляемость – характеризует степень, в которой производится управление выполнением процесса производства требуемых продуктов/услуг, отвечающих определенным целевым показателям Повторяемость – характеризует способность процесса создавать выходные потоки с одинаковыми характеристиками при повторных его реализациях Определенность – отражает степень,с которой реальный процесс соответствует описанию Эффективность – отражает, насколько оптимально используются ресурсы при достижении необходимого результата процесса Гибкость (адаптируемость)– способность процесса приспосабливаться к изменениям внешних условий, перестраиваться так, чтобы не снижались ни результативность, ни эффективность 5 Стоимость процесса - описывает финансовые затраты на процесс Раскроем понятие владельца процесса (Рис.2): Владелец процесса – это отдельное лицо, несущее полную ответственность за процесс и наделенное полномочиями в отношении этого процесса В сложных процессах - менеджер высшего уровня Владелец процесса не касается функций, выполняемых в рамках процесса отдельными департаментами. Ему важна успешная реализация всего процесса Владелец процесса - бизнес-роль, которая, в первую очередь, связана с возможностями процесса в целом, а не с повседневным выполнением производственных заданий – за это отвечают функциональные менеджеры Владелец процесса Функция 1 Отдел 1 Функция 2 Процесс Функция 3 Отдел Отдел 2 3 Рис.2 Понятие Владельца бизнес-процесса Функция 4 Отдел 4 Критерии выбора владельца процесса: Детальное знание бизнес-процесса, компетентность и профессиональные знания Возможность влиять на людей и способствовать изменениям. Надо помнить, что любые изменения будут внедряться извне функционально-линейной иерархии, поэтому существует большая вероятность конфликтов Коммуникативные способности Понимание важности порученного дела и надлежащая мотивация На Рис. 3 представлено взаимодействие Владельца процесса и Менеджера процесса: Зона ответственности владельца процесса Точка особого внимания владельца процесса Точка особого внимания владельца процесса П р о ц е с с Зона ответственности Зона ответственности функционального линейного менеджера менеджера Рис. 3 Взаимодействие Владельца процесса и Менеджера процесса В современной организации выполняется множество процессов: отгрузка готовой продукции, приход сырья на склад, прием, перевод и увольнение сотрудников. Но все процессы могут различаться по следующим признакам: 6 По масштабу По сложности По количеству задействованных исполнителей По количеству потребляемых ресурсов По потребителям выходных результатов и т.д. Обычно все процессы организации классифицируются с точки зрения отношения к основному результату деятельности организации. Дадим определение Классификации: Классификация - осуществляемое с определенной целью условное группирование любых объектов по заданным признакам. При различных целях одни и те же объекты могут быть классифицированы по разному. При этом выделяют следующие классы бизнес-процессов (Рис.4): Основные процессы - добавляют качество, кросс-функциональны в рамках предприятия, взаимодействуют как с клиентами, так и с партнерами. Должно быть выделено в качестве основных 5-8 процессов. Требуют особого внимания группы процессов: логистика выполнения заказа разработка нового продукта/услуги управление взаимоотношениями с клиентами Примеры: производство, логистика доставок/поставок планирование ресурсов, управление произвоственными мощностями Вспомогательные процессы - создают инфраструктуру организации, оказывают инфраструктурную и иную помощь. Примеры: управление финансами, управление персоналом, управление информационными ресурсами Процессы управления - отвечают за управление организацией как единой системой, реализуя функции целеполагания, планирования, контроля состояния, анализа и выработки корректирующих воздействий. Примеры: стратегическое управление, управление рисками, бюджетирование Методы моделирования бизнес-процессов Описание любого процесса включает в себя: описание последовательности функций процесса При описании необходимо использовать подход «сверху-вниз», т.е. отталкиваться от описания бизнес-процессов компании верхнего уровня, а затем, выделив процесс описывать его, последовательно детализируя. Каждый процесс представляется в виде последовательности выполняемых функций Степень детализации представления функций определяется целью описания процесса При описании последовательности функций необходимо учитывать логику выполнения (ветвления процесса) описание входов и выходов процесса (Рис. 4) описание поставщиков и потребителей процесса (Рис. 5) определение ресурсного окружения процесса (Рис.6) людские ресурсы – участники процесса (кто выполняет) производственные ресурсы – станки, оборудование, компьютеры, транспорт (при помощи чего выполняет) 7 материальные ресурсы – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет) информационные ресурсы – данные, документы, информация (на основании чего выполняет) интеллектуальные – знания и полномочия участников и владельца процесса Все эти ресурсы должны определены и описаны для каждой функции, выполняемой в процессе Варианты описания процессов: текстовый табличный графический Первичный вход, на который поступают входные потоки от первичных поставщиков, например, заявка на поставку оборудования Вторичные входы, на которые поступают ресурсы, необходимые для выполнения процесса, например, прайс-листы от потенциальных поставщиков требуемого оборудования Первичный выход, на котором формируется результата процесса (ради которого он существует), Процесс передаваемый первичным клиентам, например, заказанное оборудование Вторичные выходы, через которые вторичные продукты (потоки), не являющиеся основной целью процесса, передаются в другие процессы, например, счет на оплату заказанного оборудования передается в процесс «Оплата счетов» Рис. 4 Описание входов и выходов процесса 8 Вторичны й поставщик Процесс Первичный поставщик Первичный Косвенный Внешний Потребитель потребитель потребитель потребитель Вторичный потребитель Организация Косвенный потребитель – потребители, не получающие непосредственно первичные выходные потоки, но являющиеся следующими в цепочке. Внешний потребитель – потребитель, находящийся вне организации, но использующий выходные потоки процесса, например, розничные продавцы Потребитель – конечный потребитель выходных потоков процесса Не всегда отдельные категории потребителей присутствуют все вместе Рис. 5 Описание поставщиков и потребителей процесса Процессы Знания и полномочия персонала Персонал Продукция Документы Технические ресурсы Данные Материальные ресурсы Ресурсное окружение процессов Рис.6 Определение ресурсного окружения процесса К основным подходам моделирования относят: Структурный Процессный Объектно-ориентированный Каждый из указанных подходов будет рассматриваться далее. 9 ЖЦ внедрения ИС Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем) Модели жизненного цикла ПО Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадная модель (70-85 г.г.); спиральная модель (86-90 г.г.). В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (Рис. 7). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем: 10 на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Рис. 7Каскадная схема разработки ПО Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид (Рис. 8): Рис. 8. Реальный процесс разработки ПО по каскадной схеме Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. 11 Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (Рис. 9), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Рис.9 Спиральная модель ЖЦ CASE-средства Структурный анализ как совокупность методов моделирования сложных систем вследствие большой размерности решаемых задач должен опираться на мощные средства компьютерной поддержки, обеспечивающей автоматизацию труда системных аналитиков. Таким средством являются CASE-средства – Computer Aided Software Engineering. Большинство CASE –средств основано на парадигме – «Методология – Модель – Нотация - Средства». Дадим определения выше перечисленным компонентам: Методология – учение о структуре, логической организации, методах и средствах деятельности в области структурного анализа. Она определяет основные принципы и приемы использования моделей. 12 Модели – это совокупность символов (математических, графических и т.п.), их свойств, атрибутов и отношений между ними, которая адекватно описывает некоторые свойства моделируемого объекта. Нотации – система условных обозначений, принятая в используемой модели. Средства – аппаратное и программное обеспечение, реализующее выбранные методологию, модели и нотации. К характеристикам CASE-средств относятся: мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационной системы; использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты: репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы; средства разработки приложений, включая языки 4GL и генераторы кодов; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга. На сегодняшний день наиболее распространенными CASE-средствами в России являются: ARIS; AllFusion Modeling Suite. 13 ЛЕКЦИЯ №2 - 3 ТЕМА: Принципы структурного анализа. Базовые структурные методологии (SADT) и методология нотации (DFD, ERD). CASEсредства, поддерживающие структурный подход к проектированию ИС (AllFussion Process Modeler). Принципы структурного анализа. Базовые структурные методологии (SADT) и методология нотации (DFD, ERD) Прежде чем перейти к понятию структурного анализа, дадим следующие определения: Системный подход - методология специального научного познания и социальной практики, и также объяснительный принцип, в основе которого лежит исследование любого объекта как сложной целостной кибернетической социально-экономической системы Системный подход реализует представление сложного объекта в виде иерархической системой взаимосвязанных моделей, позволяющих фиксировать целостные свойства объекта, его структуру и динамику К основным принципам системного подхода относится: Целостность - позволяет рассматривать одновременно систему как единое целое и в то же время как подсистему для вышестоящих уровней. Иерархичность строения, т.е. наличие множества (по крайней мере двух) элементов, расположенных на основе подчинения элементов низшего уровня - элементам высшего уровня. Реализация этого принципа хорошо видна на примере любой конкретной организации. Как известно, любая организация представляет собой взаимодействие двух подсистем: управляющей и управляемой. Одна подчиняется другой. Структуризация – позволяет анализировать элементы системы и их взаимосвязи в рамках конкретной организационной структуры. Как правило, процесс функционирования системы обусловлен не столько свойствами ее отдельных элементов, сколько свойствами самой структуры. Множественность - позволяет использовать множество кибернетических, экономических и математических моделей для описания отдельных элементов и системы в целом. Применение системного подхода: Для формулирования политики и стратегии – создание всеобъемлющих и достойных планов, связывающих входы функций и процессов Для установления целей и плановых показателей – цели и ключевые показатели результативности конкретных процессов приведены в соответствие с ключевыми стратегическими целями организации Для управления операциями – более широкий взгляд на эффективность процессов, что приводит к пониманию причин проблем и проведению своевременных мероприятий по усовершенствованию Для управления персоналом – дает лучшее понимание распределения ролей и ответственности при достижении общих стратегических целей, уменьшая таким образом межфункциональные барьеры и улучшая коллективную работу Основные принципы структурного анализа: 14 Абстрагирования – выделение существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде. Формализации – заключается в необходимости строгого методологического подхода к решению проблемы. Скрытия – заключается в сокрытии несущественной на конкретном этапе информации. Полноты – заключается в контроле на присутствие лишних элементов. Непротиворечивости – заключается в обоснованности и согласованности элементов. Независимости данных – заключается в то, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, также от их физической структуры и распределения. Структурирования данных – заключается в то, что данные должны быть структурированы и иерархически организованы. Задачи структурного анализа: выявление структуры как относительно устойчивой совокупности отношений; признание методологического примата отношений над элементами в системе; частичное отвлечение от развития объектов; графическое модельное представление объектов, начинающееся с общего обзора с последующей его детализацией в виде многоуровневой иерархической структуры Типы структурных методологий: процедурно(функционально) – ориентированные - регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. информационно - ориентированные - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. - Методология ARIS является одной из таких информационно-ориентированных методологий Введем основные (базовые) понятия структурного подхода: Система – это совокупность взаимосвязанных и взаимодействующих элементов (ИСО 9000) Цель системы – достижение и сохранение желаемого состояния или желаемого результата поведения системы Система целей - совокупность взаимоувязанных целей, например: стратегические и тактические цели; долгосрочные и краткосрочные цели Связь системы с внешней средой представлена на Рис. 10. 15 Законодательство Стандарты, технические условия и т.п. Технологии Продукци я Реклам аЗаказы на сырье Отходы Информация от потребителе Материалы и й комплектующи е Персона л Финанс ы Энерги я производства Демонстрация способности обеспечения качества Прибыл ь Рис. 10 Связь системы с внешней средой Один из принципов моделирования при структурном подходе представлен на Рис.11. Модели верхнего уровня Ан кл нерие подке п кли ези та нт исан ент дент а ная ом) а По ко доку дпи мп допол мен ус сан нит ел лек лу тов ьны е т ги А кл нер нк езиие ет нт ден Пра ата на кар ове Кл ли точ рит иен чи киBac та ьP S k е в r al Bo e e ne s Ка Кл в ие рто у Bac зав чка жkеднт е ена Bon eа Ка Кл в ие рто е нBac зав чка нт щ е ед kа е Bon ен а e Bac Анkкл кеBon ие под кли пистааeнт ент нна аом) я Ан кл нер под ке ие кли ези пистаа нт ент дент нна аом) я а Ка кл рто ие Bac чка нт Анkкл а кеBo ие таne нт а у зав ж ед е ен а P S r al e e s Ка Кл е н зав рто ие Bac щ е ед чка k нт е Bon ен а а e Про зап вер кар олн ить точ ени яки За н кар ве Кл о точ ие ст Bac ву ку нт и P k юS rBoаal e e ne s - Ан кл ке ие та нт а За Кл н кар ве ие о точ Bacв куст нт и k ау Bon ю e Ка кл ртоBac ие чкаk нт а Bon e Ка кл рто ие чкаBac нт kа Bon e Кар Кл зав точBac ие ка kеднт ен Boа а ne Инф кар кл ормие а точ ция в ке нт а Кар кл точ ие Bac ка нт kа Bon e Bac k Bon e Про прав вер зап ильн кар ить олн ость точ ени ки я Кл зарег ие истри нт Bac рован k Bon e в Кар в кл точ ие Bac ка нт Анk кл а нер ке Bon ие ези таe нт дент а а Инф орм а нед ция ов стов ерна Ка Кл в ие рто зав Bac чкаед нт k ена Bon а e в Зап про в олн п необ кар вер с итьКло ходи точ ить и иее мые кеP S нтл ая r al e e s Bac k Bon e Детальные модели Рис.11 Принцип моделирования «сверху-вниз» Примеры методологий структурного анализа: DFD (Data Flow Diagrams) – диаграммы потоков данных, обеспечивающих анализ требований и функциональное проектирование информационных систем; STD (State Transition Diagram) – диаграммы перехода состояний для проектирования систем реального времени; ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь»; структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов; FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции; SADT (Structured Analysis and Design Technique – Технология структурного анализа и проектирования, 1969 -1973) – полная методология для создания описания систем, основанная на концепциях системного моделирования. 16 Связь между методологией SADT и стандартами структурного анализа (Рис.12) СТРУКТУРНЫЙ АНАЛИЗ МЕТОДОЛОГИЯ СТАНДАРТЫ ГРУППА IDEF SADT Функциональное моделирование Информационное моделирование Динамическое моделирование Рис.12 Методология SADT ее описывающие Основные принципы методологии SADT: Четкое описание цели моделирования; Фиксация единой точки зрения на моделируемую систему; Определение границ системы; Декомпозиция, обеспечивающая последовательную детализацию описания; Цель модели – получение ответов на некоторую совокупность вопросов; Точка зрения – это позиция наблюдателя, которую необходимо выбрать, чтобы увидеть систему в действие; У модели может быть только одна точка зрения!!! SADT модель должна иметь единственный субъект; В SADT-моделях используются как естественный, так и графический языки; Диаграмма – совокупность графического и соответствующего текстового описания Семейство IDEF IDEF0 - методология функционального моделирования, позволяющая описать процесс в виде иерархической системы взаимосвязанных функций; (Р50.1.028-2001. Методология функционального моделирования) IDEF1 - методология анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия; IDEF1X - методология информационного моделирования, основанная на концепции «сущность-связь». IDEF3 - методология документирования технологических процессов. IDEF4 - методология объектно-ориентированного проектирования. IDEF5 - методология, обеспечивающая наглядное представление данных обработки онтологических запросов Стандарт IDEF0 17 IDEF0 – методология структурно-функционального моделирования (моделирование процессов функционирования), позволяющая описывать бизнес-процессы в виде иерархической системы взаимосвязанных функций Достоинство функциональной модели – простота графического представления: – Функциональный блок – описание функций (действий, работ) – Интерфейсная дуга – линия, связывающая функциональные блоки и описывающая объекты (потоки объектов) Описание функциональных блоков в стандарте IDEF0 (Рис. 13) Функциональный блок – визуализируется в виде прямоугольника Название блоков должны быть глаголы в неопределенной форме с последующим дополнением (например, «Принять заказ на поставку», «Оприходовать номенклатуру на склад»). Название пишется внутри блока – должно быть лаконичным и кратким В правом нижнем углу проставляется номер блока Число блоков на одной диаграмме должно быть от 2-7 Блоки размещаются на диаграмме по степени важности или очередности выполнения – принцип доминирования Более доминирующие блоки располагаются выше и левее относительно менее доминирующих Каждый из блоков при необходимости подвергаться декомпозиции Связи основных блоков с детализирующими можно проследить по нумерации Наименование функционального блока № РЕКОМЕНДУЕТСЯ 1 НЕ РЕКОМЕНДУЕТСЯ 1 3 2 3 2 Рис. 13 Описание функциональных блоков в стандарте IDEF0 Синтаксические правила для функциональных блоков: 1. 2. 3. 4. 5. Блоки должны быть прямоугольники с прямыми углами Размеры блоков должны быть выровнены по ширине текста Имя блока должно отражать сущность функции Блоки должны быть нарисованы сплошными линиями Цвета линий различных блоков могут быть различны Спецификация сторон функциональных блоков в стандарте IDEF0 (Рис.14) 18 УПРАВЛЕНИЕ ВХОД Наименование функционально го блока № ВЫХОД МЕХАНИЗМ В результате выполнения процесса, «вход» под воздействием «управления» преобразуется в «выход» посредством «механизма» Рис.14 Спецификация сторон функциональных блоков в стандарте IDEF0 Нумерация диаграмм в стандарте IDEF0 (Рис.15) Process Name A0 Process Name Process Name A1 Process Name A2 A3 Process Name Process Name A31 A32 Рис. 15 Нумерация диаграмм в стандарте IDEF0 Описание интерфейсных дуг в стандарте IDEF0: 1. Стрелки могут состоять только из вертикальных или горизонтальных отрезков 2. Вертикальные и горизонтальные участки ломанных стрелок соединяются при помощи закруглений 3. Концы стрелок должны присоединяться к внешним границам функциональных блоков, присоединение в углах блока не допускается 4. Стрелки должны быть нарисованы сплошными линиями 5. Цвет и толщина для различных линий может быть различна 6. Дуги помечаются текстовыми метками. Метки должны быть именами существительными или существительными с определениями 7. Метки размещаются либо непосредственно на дугах, или на свободных местах диаграммы и связываются зигзагообразной линией Правила построения интерфейсных дуг в стандарте IDEF0 1. Управляющие объекты обязательно должны отражаться в функциональной модели, а входные объекты – не обязательно (например, список поставщиков, прайс-лист, список номенклатуры) 2. Механизмы – это объекты, которые выполняют процесс (должностные лица, структурные подразделения) 19 Варианты графического изображения прямых и обратных взаимосвязей в стандарте IDEF0 (Рис.16) Process Name A0 Process Name A0 Process Name A1 Process Name A1 Process Name A0 Process Name A1 Process Name A0 Process Name A1 Process Name A0 Process Name A1 Process Name A0 Process Name A1 Рис.16 Варианты графического изображения прямых и обратных взаимосвязей в стандарте IDEF0 Туннельные дуги 1. Помещение дуги в туннель является способом скрыть ее источник • • Со скрытым источником Со скрытым приемником 2. От одной стороны функционального блока не рекомендуется отводить/присоединять 5-7 дуг Пример диаграммы IDEF0 (Рис.17) 20 Рис.17 Пример диаграммы IDEF0 Предназначение IDEF 1X IDEF1Х – это метод для разработки Реляционных БД, использует удобный синтаксис, специально разработанный для удобного построения концептуальной схемы (универсальное представление структуры данных, независимо от конечной реализации БД и аппаратной платформы) Целесообразней использовать для построения логической структуры БД после того, как: – все информационные ресурсы исследованы; – решение о внедрении реляционной БД как части корпоративной информационной системы принято. Не целесообразно использовать IDEF1X для описания нереляционных систем Концепция и семантика IDEF1X (Рис.18) Сущности и их атрибуты • Сущность – конкретный набор экземпляров реального времени; • Сущность в стандарте IDEF1Х описывается в виде прямоугольника • Атрибут – признак сущности; • Разделяют Ключевые и Неключевые атрибуты сущности Связи между сущностями • Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть, глагол • У связей имеется координальность: (1,1), (1,N), (N,M) ПРИМЕРЫ: • Отдел <состоит из> нескольких Сотрудников 21 • • Самолет <перевозит> нескольких Пассажиров. Сотрудник <пишет> разные Отчеты. Рис.18 Концепция и семантика IDEF1X Идентификация сущностей. Представление о ключах (Рис. 19) Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены не ключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных Ключевая область содержит первичный ключ для сущности Первичный ключ - это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности Неключевой атрибут - это атрибут, который не был выбран ключевым Рис.19 Идентификация сущностей. Представление о ключах Правила выбора «ключа» Уникальным образом идентифицировать экземпляр сущности. Не использовать NULL значений. Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр. Быть как можно более короткими для использования индексирования и получения данных. Если вам нужно использовать ключ, являющийся комбинацией ключей из других сущностей, убедитесь в том, что каждая из частей ключа соответствует правилам. 22 ЛЕКЦИЯ №4-5 ТЕМА: Принципы процессного анализа. Базовые процессные методологии (ARIS) и нотации (модели Organization chart, Function tree, EPC, ERD). CASE-средства, поддерживающие процессный подход к проектированию ИС (ARIS). Методология и нотация ARIS. Сравнительный анализ функционального и процессного подходов Противопоставление процессного и "функционального" подхода принципиально неверно Противоречий между двумя подходами не существует - они не только дополняют друг друга, но и в известной степени должны применяться параллельно Функции, так же, как и процессы, являются равнозначными понятиями управленческой деятельности и не могут существовать в отрыве друг от друга. При этом результатом и "функционального" и процессного подходов является проектирование организационной структуры (т.е. функциональных областей) и порядка взаимодействия в ее рамках (т.е. процессов) - разница только в исходных точках проектирования: распределять ли функциональные обязанности на основе процессов или проектировать процессы взаимодействия между функциональными областями У этих двух подходов есть существенное сходство в базовых посылках: и тот и другой постулируют изначальный набор типовых процессов/функций, который в дальнейшем детализируется и привязывается к конкретному предприятию Функциональный подход отвечает на вопрос «Что делать?», процессный «Как делать?» Рассмотрим организацию с точки зрения бизнес-процессов: Предприятие – взаимосвязанная совокупность бизнес-процессов. Работа должна быть организована вокруг процессов. «Не товары, а эффективные процессы их содания приносят компаниям долгосрочный успех» (Чампи) Резервы организации – в совершенствовании процессов, преодолении их фрагментарности и улучшении ключевых показателей (затраты, качество, уровень обслуживания, оперативность) Правильно выстроенный процесс – интеллектуальное достояние компании Автоматизация существующих процессов с помощью ИТ, как правило, не дает ожидаемого эффекта Рассмотрим процессный подход к управлению организацией: сокращение зависимости процессов от функциональной иерархии («прямые» бизнеспроцессы) ориентация руководителей на способы достижения результата в рамках бизнеспроцесса, а не на управление иерархией максимальное использование квалификации сотрудников делегирование полномочии и ответственности в рамках процесса ориентация сотрудников и подразделений на конечный результат 23 устранение проблем на «стыках» между подразделениями Сущность применения процессного подхода заключается в: 1. Определить цели организации и результаты их достижения 2. Определить структуру процессов, обеспечивающих достижение желаемых результатов 3. Выявить внутренних и внешних потребителей, поставщиков и других участвующих в процессе сторон 4. Выявить и измерить входы и выходы процесса 5. Выявить интерфейсы процесса с функциями организации 6. Оценить возможный риск, его последствия и влияния процесса на потребителей, поставщиков и другие участвующие в нем стороны 7. Четко распределить ответственность, полномочия и подотчетность при управлении процессом 8. При проектировании процессов уделить внимание шагам процессов, видам деятельности, потокам, контрольным величинам, потребностям в подготовке персонала, оборудовании, методах, информации, материалов и других ресурсах, необходимых для достижения желаемого результата Применение процессного подхода дает следующие преимущества: Определить процесс достижения желаемого результата Выявить и измерить входы и выходы процесса Выявить интерфейсы процесса с функциями организации Оценить возможный риск и последствия влияния процесса на потребителей, поставщиков и другие участвующие в нем стороны Распределить ответственность, полномочия и подотчетность при управлении процессом Выявить внутренних и внешних потребителей, поставщиков и других участвующих в процессе сторон Уделить при проектировании процессов внимание шагам процессов, видам деятельности, потокам, контрольным величинам, потребностям в подготовке персонала, оборудовании, методах, информации, материалов и других ресурсах, необходимых для достижения желаемого результата Методология ARIS – пример процессного подхода к проектированию ИС: ARIS – инструментальная среда описания и анализа бизнес-процессов ARIS – лидер на рынке средств описания процессов (Рис. 20) 24 Преследователи Лидеры Возможность использования результатов ARIS Toolset Более 33 000 проданных лицензий Графические средства Участники рынка Полнота представления Источник: Gartner Group, Июнь, 2002 г. Рис.20 Возможные цели использования ARIS (Рис. 21): Цели использования ARIS Реинжиниринг существующих бизнес-процессов, их мониторинг и документирование Внедрение корпоративной информационной системы управления Управление качеством и соответствие стандартам ИСО 9000 Повышение управляемости Разграничение компании, сокращение ответственности и затрат, обоснование создание необходимости, достаточности внутрикорпоративной и эффективности регламентирующей выполнения функций документации Рис. 21 Цели использования ARIS Что дает применение ARIS: Стандарт общения в организации Удаленный доступ и публикацию проектных данных Централизованное хранение и ведение данных проекта Интеграция с SAP R/3 Использование референтных моделей IDS и отраслевых прототипов Фиксацию накопление и сохранение коллективных знаний 25 Автоматизация получения проектных документов Организация и регламентация коллективной работы команды проекта Регламентация взаимодействия Заказчика и Консультанта Основы методологии ARIS Методология ARIS представляет собой современный подход к структурированному описанию деятельности организации и представлению ее в виде взаимосвязанных и взаимодополняющих графических моделей, удобных для понимания и анализа Методология ARIS основывается на концепции интеграции, предлагающей целостный взгляд на процессы, и представляет собой множество различных методик, объединенных в рамках единого системного подхода, такие известные как: диаграммы eEPC (Extended Event driven Process Chain - событийная цепочка процесса) модели ERM – (Entity Relationship Model – модель «сущность-связь») язык UML (Unified Modeling Language – универсальный язык моделирования) методики OMT (Object Modeling Technique – методика объектноориентированного моделирования) методика ABC (Activity Based Costing – пооперационный расчет стоимости процессов) методики BSC (Balanced Scorecard – система сбалансированных показателей) Уровни описания ARIS (Рис. 22 -23): Организационное представление Функциональное представление Процессное представление Представление на уровне данных На каждом из выше указанных уровней предметная область описывается на следующих подуровнях: Определение требований Спецификация проекта Описание реализации 26 Кто План Or и-g 5 рован ие Кл 2 ET ие нт ы Зак ET 1 аз ы Пр 3 ET од укт ы На основе чего Данные Произ водст Снабво жени е Кл 2 ET ие нт ы Пред прият ие Организаци я Отде л прода ж Зап E1 рос от кли Обра F 11 ент ботка а запро са Зап E2 рос обр або Соста F 12 тан влени е заказ а Каким образо м Отде л прода ж Процессы Что Обсл F1 ужив ание Обра F 11 клие Сост F 12 ботк нтов авле а ние F 111 заказ запр Сост оса авит а ь Опре F 112 номе дели нкла ть туру цены Функции Рис.22 Анализ проблем бизнеса Определение (Семантические модели) требований Спецификация (Описания, ориентированные на проекта информационные технологии) Описание (На уровне информационных реализации технологий) Реализаци я (информационные технологии) Рис.23 Инструментальная система ARIS: 105 типов моделей для описания деятельности предприятия Более 250 типов объектов, описывающих различные аспекты предметных областей Более 600 различных типов связей, описывающих различные отношения между объектами предметной области Встроенные механизмы управления, проверки, анализа, экспорта/импорта, архивирования моделей Возможные действия над моделями: Семантические проверки корректности моделей Cоставление отчетов по моделям Сравнение моделей Организация и управление непрерывным улучшением модели Копирование моделей Создание вариантов моделей Генерация моделей на основе существующих моделей 27 Перенос моделей из одной базы данных в другую Экспорт/импорт моделей в другие программные системы Хранение моделей, в том числе и в виде резервных копий Очищение моделей от неиспользуемых объектов Консолидация множественных определений объектов моделей Архитектура ARIS Возможные конфигурации среды ARIS (Рис. 24): Индивидуальный сервер Выделенный сервер баз данных Несколько выделенных серверов ARIS Рис.24 Конфигурации ARIS Семейство программных продуктов ARIS фирмы IDS Scheer AG (Рис.25): 28 ARIS Business Architect ARIS Business Designer ARIS Toolset ARIS Easy Design ARIS Business Publisher ARIS Web Publisher ARIS Business Process Management Portal ARIS Simulation ARIS Quality Management Scout ARIS Scout Factory ARIS BSC ARIS BSC Portal ARIS Business Optimizer ARIS ARIS ARIS ARIS for SAP NetWeaver UML Designer Redocumentation Scout Software Engineering Scout ARIS ARIS ARIS ARIS Audit Manager Process Performance Manager Process Cost Analyzer Process Risk Scout ARIS Business Server Рис. 25 Семейство программных продуктов ARIS фирмы IDS Scheer AG Рассмотрим функциональное насыщение основных компонент платформы ARIS: ARIS Easy Design Графическая среда для моделирования бизнес-процессов Поддержка многоязычных моделей Конфигурация клиент-сервер Стандартный интерфейс Explorer Windows Возможность доступа в Internet ARIS Toolset Дополнительные функции (к функциям ARIS Easy Design) конфигурация/настройка фильтров определение форм отчетов консолидация объектов проверка соответствия модельным соглашениям анимация «бизнес-вариантов» ведение репозитория ARIS ABC Дополнительный модуль, подключаемый к среде ARIS Toolset, позволяющий реализовывать анализ стоимости бизнес-процессов на основе ABC-методологии 29 ARIS Simulation Модуль имитационного моделирования. Используется в случае необходимости динамического моделирования разработанных моделей бизнес-процессов. ARIS BSC Модуль стратегического анализа и управления. Позволяет анализировать достижение стратегических целей и их взаимосвязь с текущей деятельностью. Модуль ARIS Quality Management Scout Модуль ARIS Quality Management Scout может быть использован при создании процессно-ориентированной системы управления качеством или при приведении существующей системы управления качеством в соответствие требованиям стандартов ISO 9000:2000. ARIS Quality Management Scout предоставляет проверочные листы, вопросники по аудиту СМК и другую помощь, облегчающую выполнение индивидуальных действий. Модуль ARIS Process Risk Scout Модуль ARIS Process Risk Scout – это инструментальное средство, предназначенное для создания и эксплуатации системы управления рисками. ARIS Process Risk Scout охватывает полный жизненный цикл проекта по управлению рисками от определения политики в отношении рисков и их анализа до быстрого получения отчетов о рисках всей компании и управления ими. Модуль ARIS Process Performance Manager ARIS Process Performance Manager автоматически собирает данные о производительности непосредственно из бизнес-процессов компании, в частности, данные из нескольких различных информационных систем, например, таких как ERP-, SCM- и CRM-системы. Главную роль играют бизнес-процессы, реализованные в качестве информационных систем фирмы SAP ARIS Web Publisher ARIS Web Publisher используется в тех случаях, когда надо разместить информацию о бизнес-процессах в Интернет. Модуль ARIS Web Publisher помогает публиковать модели бизнес-процессов в Интернет и интранет. Web-интерфейс модуля позволяет всем служащим компании сразу знакомиться со всеми изменениями бизнес-процессов, позволяет преодолевать пространственные и географические барьеры между различными подразделениями компании. 30 Модуль ARIS Web Designer Модуль ARIS Web Designer позволяет всем территориально удаленным служащим компании совместно проектировать бизнес-процессы. Он обеспечивает пользователям компании доступ к центральной базе данных бизнес-процессов. ARIS Server Модуль, необходимый для поддержки коллективной работы, который содержит: средства организации многопользовательского режима, управления работой пользователей хранилище, используемое всеми подключенными пользователями средства обмена данными между БД проектов средства проверки на непротиворечивость внутреннего представления данных Организационное представление ARIS Диаграммы организационного представления ARIS (Рис. 26) Организационные модели (5) Модели определения требований (2) Календарный график (Shift calendar) Организационная диаграмма (Organizational chart) Модели спецификации проекта (1) Топология сети (Network topology) Модели описания реализации (2) Диаграмма сети (Network diagram) Технические ресурсы (Technical resources ) Рис.26 Диаграммы организационного представления ARIS Организационная схема (Organizational chat) – предназначена для моделирования организационной структуры предприятия с различной степенью детализации. Объекты организационной диаграммы (Рис. 27): Рис.27 Объекты организационной диаграммы 31 1. Соединение 2. Тип организационной единицы 3. Тип организационной единицы 4. Организационная единица 5. Организационная единица 6. Центр стоимости 7. Тип должности 8. Должность 9. Тип системной организационной единицы 10. Тип системной организационной единицы 11. Тип системной организационной единицы 12. Тип системной организационной единицы 13. Тип сотрудника 14. Штатный сотрудник 15. Внештатный сотрудник 16. Группа 17. Расположение 18. Организационная схема 19. Рабочая станция 20. Описание должности Типы связей организационной диаграммы: 1. Принадлежит 2. Может являться частью 3. Может быть непосредственным руководителем 4. Может быть техническим руководителем 5. Может принадлежать 6. Взаимодействует с 7. Описывает 8. Связан(а) с 9. Имеет отношение1:1 (1:n, n:m) 10. Состоит из 11. Является непосредственным руководителем 12. Располагается 13. Находится под управлением 14. Относится к типу 15. Является организационным управляющим 16. Является должностью 17. Отвечает за 18. Имеет в подчинении 19. Является техническим руководителям 20. Связан(а) с 21. Имеет в своем составе 22. Занимает 23. Формирует 24. Замещает 25. Содержит 32 Пример модели Organizational chat (Рис.28) Генеральный директор указание подчиненности должностей is Organization Manager for Главный occupies петров П.П. бухгалтер Директор по производству Указание подчиненности подразделения должности is Organization Manager for Производство Бухгалтерия is composed of указание состава подразделения Указание должности, занимаемой сотрудником is composed of occupies Начальник Бухгалтер цеха is Organization Manager for is of type Петров П.П. Ответственный за расчеты Цех is composed of Оператор 1 Бизнес-роль - некоторый набор Указание бизнесфункциональных обязанностей, роли сотрудника закрепляемых за определенной должностью Оператор 2 Рис. 28 Пример модели Organizational chat Типовые оргструктуры предприятий Общая концепция бюрократических организационных структур: четкое разделение труда, использование квалифицированных специалистов; иерархичность управления, при которой нижестоящий уровень подчиняется и контролируется вышестоящим; наличие формальных правил и норм, обеспечивающих однородность выполнения руководителями своих задач и обязанностей; дух формальной обезличенности, характерной для выполнения официальными лицами своих обязанностей; осуществление найма на работу в соответствии с квалификационными требованиями к данной должности, а не с субъективными оценками. Виды бюрократических структур управления организациями Линейная организация (Рис. 29) Ру ков одитель is disciplinary superior to is disciplinary superior to Линейный ру ков одитель А (фу нкции а,б) Линейный ру ков одитель Б (фу нкции а,б) is organization manager f or Исполнитель Исполнитель is organization manager f or Исполнитель Исполнитель Исполнитель Исполнитель Рис.29 Линейная организация 33 Функциональная организация (Рис.30) Ру ков одитель is disciplinary superior to is disciplinary superior to Фу нкциональный ру ков одитель (фу нкции а) Фу нкциональный ру ков одитель (фу нкции б) is organization manager f or is organization manager f or Исполнитель Исполнитель Исполнитель Рис.30 Функциональная организация Линейно-функциональная структура (Рис.31) Генеральн ыйдирект ор Заместитель финансовым по вопросам Заместитель по развития вопросам компании Бухгалтер ия Отде маркетин л га Финансов ыйотде л Юридическ ий отде л Финансов менедж ый ер Специали по ст кредитам Экономи ст Заместитель по кадровой вопросам политики Служ безопасно ба сти Начальн юротде ик ла Хозяйственн ый отде л Юрис т Юрист общим по вопросам Юрист по 1 договорам Групп инвестиц а ий Отде кадро л в Групп реклам а ы Касс а Рис.31 Линейно-функциональная структура Линейно-штабная структура (Рис.32) Ру ков одитель Штаб is disciplinary superior to Линейный ру ков одитель А Штаб Линейный ру ков одитель Б is organization manager f or Исполнитель Штаб is organization manager f or Исполнитель Исполнитель Исполнитель Рис. 32 Линейно-штабная структура 34 Дивизиональная структура (Рис.33) Ру ков одитель is disciplinary superior to Ру ков одитель подразделения-1 is disciplinary superior to Помощники is disciplinary superior to is disciplinary superior to Ру ков одитель подразделения-2 is disciplinary superior to Помощники Ру ков одитель подразделения-3 is disciplinary superior to Помощники is organization manager f or is organization manager f or is organization manager f or Фу нкциональное подразделение-1 Фу нкциональное подразделение-2 Фу нкциональное подразделение-3 Рис.33 Дивизиональная структура Виды органических (адаптивных ) структур управления организациями Проектная структура Основным принципом построения проектной структуры является концепция проекта, под которым понимается любое целенаправленное изменение в системе. Деятельность предприятия рассматривается как совокупность выполняемых проектов, каждый из которых имеет фиксированное начало и окончание. Каждый проект имеет свою структуру, и управление проектом включает определение его целей, формирование структуры, планирование и организацию работ, координацию действий исполнителей. После выполнения проекта структура проекта распадается, ее компоненты, включая сотрудников, переходят в новый проект или увольняются (если они работали на контрактной основе). По форме структура управления по проектам может соответствовать как бригадной (кросс-функциональной) структуре, так и дивизионной структуре, в которой определенный дивизион (отделение) существует не постоянно, а на срок выполнения проекта. Матричная структура (программно-целевая) Матричная структура представляет собой сетевую структуру, построенную на принципе двойного подчинения исполнителей: - непосредственному руководителю функциональной службы, которая предоставляет персонал и техническую помощь руководителю проекта - руководителю проекта или целевой программы, который наделен необходимыми полномочиями для осуществления процесса управления. 35 При такой организации руководитель проекта взаимодействует с 2-мя группами подчиненных: - с постоянными членами проектной группы - с другими работниками функциональных отделов, которые подчиняются ему временно и по ограниченному кругу вопросов. При этом сохраняется их подчинение непосредственным руководителям подразделений, отделов, служб. Для деятельности, которая имеет четко выраженное начало и окончание, формируют проекты, для постоянной деятельности - целевые программы. В организации и проекты, и целевые программы могут сосуществовать. Бригадная структура (кросс - функциональная) автономная работа рабочих групп (бригад); самостоятельное принятие решений рабочими группами и координация деятельности по горизонтали; замена жестких управленческих связей бюрократического типа гибкими связями; привлечение для разработки и решения задач сотрудников разных подразделений. Функциональное представление ARIS Дерево функций (Function Tree) – представляет иерархическое декомпозицию функций на подфункции: Дерево функций отображает статическую декомпозицию функций. Основные объекты модели: функция, связь функций Существует несколько способов декомпозиции функций Функция характеризуется временем и стоимостью. Типы декомпозиций функций: Процессно-ориентированная подчиненность (Is process-oriented superior) - выделение функций по принадлежности к одному процессу, то есть все выделенные функции являются этапами одного процесса. Критерием процессно–ориентированной детализации служат операции, которые выполняются над различными объектами в рамках бизнеспроцесса. Объектно-ориентированная подчиненность (Is object-oriented superior)выделение функций, выполняемых над одним объектом. Эти функции описывают различные операции, выполняемые над одним и тем же объектом. Операционно-ориентированная подчиненность (Is execution-oriented superior) - при операционно-ориентированном подходе функция верхнего уровня декомпозируется на подфункции, каждая из которых выполняет ту же операцию, но с различными объектами. Функции могут принадлежать различным процессам и привлекаться к обработке различных объектов. Однако выполняемый ими тип операции над отдельными объектами всегда один и тот же. 36 Диаграммы функционального представления ARIS (Рис.34): Функциональные модели (7) Модели определения требований (5) Диаграмма целей (Objective diagram) Дерево функций (Function tree) Модель функций SAP ALE (SAP ALE Function Model) Диаграмма SAP приложений (SAP Applications Diagram) Y-диаграмма (Y-Diagram) Модели спецификации проекта (1) Диаграмма типов прикладных систем (Applications System Type Diagram) Модели описания реализации (1) Диаграмма прикладных систем (Applications System Diagram) Рис. 34 Диаграммы функционального представления ARIS Типы объектов и связей дерева функций (Рис. 35) 1 2 Рис.35 Типы объектов и связей дерева функций 1. Связь: Is process-oriented superior - процессно-ориентированная подчиненность Is object-oriented superior - объектно-ориентированная подчиненность Is execution-oriented superior - операционно-ориентированная подчиненность 2. Функция 37 Пример дерева функций (Рис. 36) Функции необходимые для обеспечения проектной деятельности Функции, связанные с проектным заданием Функции управления взаимосвязями Функции, связанные со сроками Функции, связанные с затратами Функции, связанные с ресурсами Открытие проекта Определение работ проекта Планирование соподчиненности работ Оценка затрат Разработка плана проекта Осуществление коонтроля за выполнением работ Построение календарного графика работ Составление бюджета Обеспечение Обеспечение Документирование контроля взаимодействия характеристик за выполнением в течении проекта продукта проекта графика работ Обеспечение Обеспечение контроля за менеджмента характеристиками изменений продукта Функции, Функции, связанные связанные с распространением с персоналом информации Функции, связанные с управлением рисками Планирование Планирование Определение орг. информационных ресурсов структуры проекта потоков Контроль за ресурсами Выделение штата Управление информацией Контроль за информационными потоками Контроль за затратами Функции, связанные с МТС Определение рисков Планирование и контроль закупок Документирование Контроль за коммерческих и рисками технических требований Оценка субподрядчиков Заключение субподрядов Контроль за выполнением контрактов Рис. 36 Дерево функций Процессное представление ARIS Событийная цепочка процесса. Диаграмма eEPC Событийная цепочка процесса (Extended event driven process chain - eEPC) описывает последовательность функциональных шагов (действий) в рамках одного бизнес-процесса, которые выполняются организационными единицами и позволяет осуществлять связь между организационной и функциональной моделями Используется для описания сценария процесса и процедур Основные объекты диаграммы eEPC (Рис.36) Поступил заказ Событие Логическое правило Принять заказ Обработка заказа клиента Менеджер по персоналу Функция Интерфейс процесса Объекты организационной диаграммы 38 Documen t Lis t Draft list Fil e Bar code Microfich e Folde r Card file File cabinet 8:00 ____ Electronic document Lette r Boo k Notepa d 12:00 ___ Time planner Fa x Interne t Magnetic tape Telephon e Intrane t Extrane t Diskett e Hard disk Mobile phone LA N CDROM Printe r Filing basket Email Electronic folder DV D Information carrier Рис. 36 Основные объекты диаграммы eEPC Пример eEPC (Рис.37) Наличие необходимых средств Рекламмные материалы Потребность ПУ - процессное в переходе управление к ПУ предприятием Аннотированный перечень ИТ компаний Изучить рынок Сведения об ИТ компании Отдел ИТ Знания, необходимые для выполнения функции ИТ компания выбрана ИТ - информационные технологии Знания персонала Обучать персонал Приобрести ARIS Персонал обучен ARIS приобретен Знания по ARIS Знания, получаемые при выполнении функции Документация по ARIS Знания, получаемые при покупке ARIS Начато внедрение ARIS Рис.37 Пример eEPC 39 Правила использования логических операторов в eEPC моделях (Рис.38): Событие 1 Событие 2 «И» «ИЛИ» Исключающее ИЛИ Функция выполнится, если наступили оба события Функция выполнится, если наступило одно из событий, либо оба сразу Функция выполнится, если наступило либо одно событие, либо другое, но не оба сразу При выполнении функции наступают оба события При выполнении функции наступают либо одно событие, либо другое, либо оба сразу При выполнении функции наступает либо одно событие, либо другое, но не оба сразу «И» «ИЛИ» Исключающее ИЛИ Функция Функция Событие 1 Событие 2 Функция 1 Функция 2 Событие Событие Функция 1 Функция 2 Событие наступит, Событие наступит, если выполнятся если выполнится либо одна функция, обе функции либо другая функция, либо обе сразу При наступлении события выполнятся обе функции Запрещенная ситуация, т.к. событие не может принимать решения Событие наступит, если выполнится либо одна функция, либо другая функция, но не обе сразу Запрещенная ситуация, т.к. событие не может принимать решения Рис. 38 Правила использования логических операторов в eEPC моделях Существует несколько разновидностей eEPC моделей: eEPC (в виде столбцов) eEPC (column display) еEPC (уровень экземпляров) eEPC (instance) eEPC (с потоками материалов) eEPC (material flow) eEPC (в виде строк) eEPC (row display) еEPC (в виде таблицы) eEPC table displa 40 ЛЕКЦИЯ №6 ТЕМА: Основные подходы к реорганизации бизнес-процессов: принципы Э. Деминга, японская парадигма улучшения бизнеспроцессов (TQM, 6-сигм), BPR (принципы Хаммера/Чампи). Сформулируем базовые определения: Реорганизация бизнес-процесса - целенаправленное изменение бизнеспроцесса за счет изменения состава его процедур и/или их параметров, логики процесса, системы принятия решений в рамках процесса, информационного обеспечения и т.д. Проект реорганизации бизнес-процессов - проект, основная цель которого состоит в построении на предприятии более эффективных бизнес-процессов. Эффективность бизнес-процессов может измеряться по заданным критериям как по отношению к существующим на предприятии процессам, так и по отношению к процессам конкурентов Эффективность бизнес-процесса – отношение конечного результата (выхода) процесса к затраченным на его получение ресурсам. Может измеряться на основе различных критериев Критерий оценки эффективности бизнес-процесса - качественный или количественный показатель, рассчитываемый по определенной методике и характеризующий результат и/или динамические параметры функционирования бизнес-процесса Анализ эффективности бизнес-процесса – анализ результатов выполнения бизнес-процесса и/или параметров, характеризующих выполнение процесса в динамике, и сравнение полученных показателей с затратами (временными, финансовыми, материальными, человеческими), необходимыми для осуществления данного процесса, и/или целевыми показателями эффективности процесса. Анализ эффективности может проводиться так же путем сравнения по заданным показателям нескольких процессов, предназначенных для получения определенного конечного результата Основные принципы реинжиниринга Рассмотрим основные принципы реинжиниринга: Принципы Хаммера Организовывайте достижение результата, а не выполнение задачи Поручите исполнение процесса тем, кто использует его результат Включайте обработку информации в реальную работу, которая генерирует эту информацию Считайте географически распыленные ресурсы централизованными Связывайте параллельные работы вместо интеграции их результатов Помещайте точку принятия решения туда, где делается работа, и встраивайте контроль в процесс Фиксируйте информацию один раз - у источника Принципы качества Э. Деминга 41 Теория Всеобщего управления качеством или Тотального менеджмента качества (Total Quality Management, TQM), как философская концепция, возникла в результате развития и обобщения мыслей выдающихся людей своего времени — Э. Деминга, Дж. Джурана, Ф. Кросби, Т. Сейфи, С. Синго, А. Фейгенбаума, В. Шухарта. Их взгляды на управление качеством несколько отличались, однако общим для них было то, что все они опирались на одну гуманистическую идею и оказали огромное влияние на мировую экономику. Суть этой идеи очень проста и понятна — производитель создает продукцию или оказывает услугу такого качества, которое востребовано конкретным покупателем. При этом хозяин производства выстраивает со своими рабочими и служащими совершенно определенные отношения, стимулирующие и мотивирующие их на непрерывное самосовершенствование и постоянное улучшение качества продукции. Концепция Всеобщего управления качеством использует два понятия — внешнего потребителя — людей, для которых создается продукция, и внутреннего потребителя — людей, которые своими знаниями, способностями, талантом и оплаченным трудом создают продукцию требуемого качества. Очевидно потому, что идеи TQM предполагают труд одних людей для удовлетворения потребностей других людей, они стали востребованы мировым сообществом. За очень короткое время тотальный менеджмент качества из привлекательной теории превратился в эффективный метод управления предприятиями и организациями и завоевал мировое признание как стратегическое средство обеспечения высокого качества продукции при минимизации затрат. Не смотря на свою практичность, TQM – это, прежде всего, мировоззрение, система отношений между людьми, философия предприятия. Фундамент концепции всеобщего управления качеством был заложен в экономической программе Э. Деминга, сформулированной им в Токио на семинаре Союза японских ученых и инженеров в 1950 году. Эдвардс Деминг в то время возглавлял одну из групп специалистов, прибывших в Японию по просьбе правительства в рамках плана Маршала. Программа построения системы менеджмента качества, разработанная комиссией, была основана на «трех прагматических аксиомах» и «14 принципах». Первая аксиома утверждает: «Любая деятельность может рассматриваться, как технологический процесс и потому может быть улучшена ». Вторая аксиома гласит: «Производство следует рассматривать как систему. Поэтому решения частных конкретных проблем совершенно не достаточно. Необходимы системные фундаментальные изменения». Третья аксиома требует: «Высшее руководство предприятия должно во всех случаях поступать так, чтобы принять на себя ответственность за деятельность предприятия». Принцип 1. Постоянство целей: «Сделайте так, чтобы стремление к улучшению продукции или услуг стало постоянным. Ваша конечная цель — быть конкурентоспособным в бизнесе и создавать рабочие места. Не отступайте от достижения четко сформулированных производственных целей, поэтапного и постоянного улучшения качества продукции и услуг». Принцип 2. Лидерство и ответственность: «В новых социальноэкономических условиях менеджеры - лидеры организации должны ответить на вызовы внешней среды, осознать свою ответственность и взять на себя руководство позитивными изменениями». Принцип 3. Отказ от массового контроля: «Для достижения требуемого качества продукции нет необходимости в массовом контроле, поскольку 42 качество от него не зависит. Качество – результат оптимизации процессов производства, а не контроля конечной продукции». Принцип 4. Отказ от закупок по самой низкой цене: «Следует прекратить практику приобретения самых дешевых ресурсов для производства продукции и оказания услуг. Цена не имеет смысла без определения свойств товара. Дешевые ресурсы, как правило, могут иметь соответствующее качество, и оно не позволит вам обеспечить требуемое качество ваших товаров и услуг». Принцип 5. Ориентация на процессы: «Качество должно «встраиваться» в продукцию на этапе ее проектирования. На этапе планирования производства уже будет поздно. Качество начинается с целей». Принцип 6. Подготовка и переподготовка персонала: «Организация должна иметь систему подготовки и переподготовки персонала на рабочих местах с использованием современных методов обучения, тестирования и аттестации». Принцип 7. Учреждение лидерства: «В организации должна быть создана система эффективного руководства. Проверки и инспекции должны быть направлены на то, чтобы помочь сотрудникам лучше выполнять их работу». Принцип 8. Корпоративная культура: «Организация должна изучать и целенаправленно формировать свою корпоративную культуру. Важно создать благоприятный « микроклимат » в коллективе, используя эффективные методы общения между сотрудниками, препятствовать возникновению атмосферы страха и недоверия. Работники предприятия должны чувствовать себя защищенными, не бояться задавать вопросы и высказывать свои мысли». Принцип 9. Системный подход: «Организация должна управляться на основе системного подхода. Внутри производственные отношения должны иметь характер «клиент-поставщик». Принцип 10. Отказ от пустых лозунгов и призывов: «Руководителям организации следует отказаться от не подкрепленных соответствующими ресурсами лозунгов, призывов к действиям и проповедей для «мобилизации масс на трудовые подвиги» во имя достижения каких-либо целей - повышения эффективности производства, качества продукции и т.д.». Принцип 11. Отказ от объективистских методов управления: «Менеджеры не должны злоупотреблять использованием количественных показателей для управления организацией. Для того, чтобы грамотно управлять необходимо «познать суть вещей», а не доверяться только «сухим цифрам». Принцип 12. Гордость своей работой: «В организации следует создать условия, при которых сотрудники могут и должны гордиться своей работой. Сотрудник, который чувствует свою необходимость, не пожалеет усилий, чтобы ее сохранить. Он будет работать лучше, если будет знать, что нужен организации, и гордиться этим». Принцип 13. Повышение квалификации персонала: «Организация должна разработать и ввести в действие систему повышения квалификации персонала и создать каждому сотруднику условия для его самосовершенствования. Необходимо поощрять образование и самообразование сотрудников. Организации нужны не просто хорошие 43 работники, ей нужны работники, которые становятся лучше, благодаря образованию и самосовершенствованию». Принцип 14. Приверженность повышению качества: «Высшее руководство организации должно четко и ясно заявить о своей приверженности постоянному улучшению качества продукции и услуг и непрерывно доказывать это своими действиями». Вывод Система Всеобщего управления качеством – это метод управления производством Концепция улучшения бизнес-процессов Концепция улучшения бизнес-процессов основывается на двух подходах: Методика быстрого анализа решения (FAST) «Прорывной» подход, концентрирует внимание проектной группы на определенном процессе в ходе 1-2-дневного совещания для определения способов, которыми группа может улучшить этот процесс в течение следующих 90 дней. Перед окончанием совещания руководство отвергает или принимает предложенные улучшения. Бенчмаркинг процесса Систематический метод определения, понимания и развития товаров, услуг, проектов, оборудования, процессов и процедур более высокого качества для улучшения текущей деятельности организации, посредством изучения того, как разные организации выполняют одинаковые или похожие операции. Общие причины неудач реинжиниринга бизнес-процессов Некорректная постановка целей проекта Отсутствие профессионального руководителя проекта, недостаточные полномочия, нечеткие планы Недостаточное внимание руководства предприятия промежуточным результатам проекта Неэффективное применение инструмента моделирования бизнес-процессов Отсутствие утвержденной методики моделирования и реорганизации Недостаточное освещение целей и результатов проекта внутри предприятия Сопротивление изменениям Нехватка ресурсов, затягивание проекта 44 ЛЕКЦИЯ №7 ТЕМА: Сравнительный анализ подходов к проектированию ИС. Введение в проблему На сегодняшний момент статистика успешности ведения проектов автоматизации не утешительна, только 25 процентов проектов заканчиваются успехом. В то же время, обязательным условием успешности развития, работы и конкурентоспособности любого крупного предприятия является наличие корпоративной информационной системы. Высокая динамика изменения ситуации на рынке предъявляет жесткие требования, как к функциональности ИС, так и к процессу создания ИС. Современные средства позволяют достаточно быстро создавать (внедрять) ИС по готовым требованиям. Но очень часто оказывается, что эти системы не удовлетворяют заказчиков. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС. Проблема формирования требований к ИС остается до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении конечного результата. Поэтому для создания адекватной информационной системы нужна технология, которая бы помогла сформировать требования к ИС, спроектировать и разработать систему, отвечающую этим требованиям. Наличие такой технологии (особенно при параллельном ведении большого количества проектов) является решающим фактором успеха при создании ИС. Поскольку этапы анализа и проектирования вне зависимости от модели ЖЦ являются определяющими при построении корпоративных информационных систем, в работе представлен анализ современных методик анализа и проектирования на предмет их применимости в различных типах проектов. Важность такого исследования обусловлена, с одной стороны, тем, что разработчики обычно регламентируют свои средства (подходы, нотации), как универсальные, а с другой, тем, что полноценная информация по методологии использования подходов практически отсутствует. Сравнительный анализ подходов проводился на основе анализа сильных и слабых сторон подходов, а также опыта их практического применения в проектах автоматизации. Подходы к проектированию ИС В настоящее время используется большое количество подходов, которые позволяют, так или иначе, создавать модели бизнес-процессов предприятий. Важнейшими из подходов являются структурный (функциональный), объектноориентированный, процессный подход (например, методология ARIS). Сравним данные подходы. 1. Структурный (функциональный) подход Сущность подхода 45 Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. В качестве средств структурного анализа и проектирования, наиболее распространенны следующие нотации: SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF0) применяется для определения требований (функций) для разработки системы, реализующей выделенные функции. Для уже существующих - IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм (Рис.39). Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция). Рис.39 Модель в нотации IDEF0 DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0. IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций. ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X). Выводы по практическому использованию Общие выводы: применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов на этапе анализа. Выводы по диаграммам: Наиболее существенное различие между разновидностями структурного анализа заключается в их функциональности. Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Таким образом, четко прослеживается логика и взаимодействие процессов организации. Главным достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко 46 регламентированной структуре. С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д. DFD позволяет проанализировать информационное пространство системы и используется для описания документооборота и обработки информации. Поэтому диаграммы DFD применяют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0. IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени. Нельзя говорить о достоинствах и недостатках отдельных нотаций. Возможны ситуации, при которых анализ IDEF0 не обнаружил недостатков в деятельности организации с точки зрения технологического или производственного процесса, однако это не является гарантией отсутствия ошибок. Поэтому в следующем этапе анализа необходимо перейти к исследованию информационных потоков с помощью DFD и затем объединить эти пространства с помощью последней нотации - IDEF3. Что касается IDEF1X, наряду со многими достоинствами, существенным недостатком является невозможность адекватно и полно описать предметную область. Поэтому, код клиентского приложения, генерируемый в дальнейшем на основе информации о структуре БД, не позволяет построить эффективное приложение со сложной бизнес – логикой. Это вызвано тем, что данные для хранения в БД необходимо представить в таблицах, к структуре которой предъявляются требования нормализации. 2. Объектно-ориентированный подход Сущность подхода Принципиальное различие между структурным и объектно-ориентированным (ОО) подходом заключается в способе декомпозиции системы (Рис.40). ОО подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами Рис. 40 Сравнительный анализ объектно-ориентированной и функциональноориентированной декомпозиций 47 В 90-е годы появилось большое количество различных методологий с собственными наборами нотаций. Самые популярные – ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону). UML (Unified Modeling Language) –стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) в 1997г. UML предоставляет средства для создания визуальных моделей, которые единообразно понимаются всеми разработчиками, вовлеченными в проект, и являются средством коммуникации в рамках проекта. Диаграмма в UML - это графическое представление набора элементов. Диаграммы рисуют для визуализации системы с разных точек зрения. При визуальном моделировании на UML используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Выводы по практическому использованию Общие выводы: в настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения UML на этапах анализа и проектирования описана достаточно слабо (т.е. можно найти описание диаграмм, но логика их использования регламентируется слабо), поэтому рано говорить о UML как о действительно полноценной замене всем другим подходам. Выводы по диаграммам: В языке UML для этапов анализа предназначены следующие виды диаграмм: use case diagram (диаграммы прецедентов); activity diagram (диаграммы описаний технологий, процессов, функций); sequence diagram (диаграммы последовательностей действий); collaboration diagram (диаграммы взаимодействий). Проанализируем их функциональную пригодность для этих целей. Use case diagram – рекламируется разработчиками как альтернативный инструмент анализа вместо стандартных структурных нотаций. Однако, описывая функции системы (прецеденты) и их исполнителей (актеры), не позволяет проанализировать существующую модель бизнес-процессов и выявить ее недостатки, также к другим минусам можно отнести недостаточную степень регламентации описания функции (невозможно проследить механизмы и управление процессом) и невозможность проследить их логику взаимодействия. Плюсом диаграммы является ее простота, наглядность и читабельность неспециалистами. Фактически является некоторым аналогом нотации IDEF0 (прецедент – работа, актер – один из механизмов). Activity diagram – представляют собой схемы потоков управления в системе от действия к действию, а также параллельные и альтернативные потоки, с является неким аналогом нотаций IDEF0 и IDEF3. Т.е. понятие «перекресток» заменяется элементами «линия синхронизации» и «выбор», а «работа» - «действием». Диаграмма не очень приспособлена для отображения сложной логики, но возможно ее использование в качестве доступного для понимания аналога заказчику. Дуги Use Case и Activity диаграмм не имеют смысловых типов, которые указаны для дуг IDEF0. Использование данных диаграмм требует установления дополнительных синтаксических соглашений, т.к. UML нежесткий язык и допускает построение синтаксически корректных Activity-диаграмм, не имеющих смысла или не поддающихся объяснению. Например, чтобы определить тип входящей стрелки, различать документы, можно их выделять цветом, использовать пунктирные и сплошные стрелки и т.п. 48 Sequence diagram – иллюстрирует события, инициированные в системе исполнителями. Если изобразить диаграмму на абстрактном уровне в терминах предметной области, а систему рассматриваются как "черный ящик", то она является достаточно удобным инструментом для построения общей информационной модели. Т.е. входное сообщение является входной информацией в терминах IDEF0, а отклик системы (объекта) – выходной информацией. Является удобной диаграммой при переходе на физический уровень, как при проектировании графического интерфейса, так и при переходе к классам и физической реализации (сообщения становятся методами соответствующего класса). Для этапа проектирования однозначно определены: State diagram (диаграммы состояний); Class diagram (диаграммы классов). Component diagram (диаграммы компонент); Deployment diagram (диаграммы развертывания). Основной диаграммой UML является Class diagram, которая является основой для генерации кода и основной целью проектирования. Является визуальным представлением идеи объектно-ориентированного проектирования и программирования. Действительно плюсом является легкость исправления проектного решения в соответствии с изменившейся бизнес-логикой, т.к. в динамически построенной модели нет необходимости полной перестройки, присущей нотациям структурного подхода. В частности, изменение отдельных классов и связей между ними не затронет общей концепции модели. 3. Методология ARIS Сущность подхода Методология ARIS определяет принципы моделирования различных аспектов деятельности организаций, основывается на концепции интеграции, предлагающей целостный взгляд на бизнес-процессы, и представляет собой множество различных методологий, интегрированных в рамках единого системного подхода – моделирование на 4-уровнях: организационном, функциональном, процессном и уровне данных. Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п. К преимуществам методологии ARIS разработчики относят следующие: возможность рассматривать объект с разных точек зрения: при анализе деятельности каждому аспекту можно уделять достаточное внимание и только после детального изучения всех аспектов можно перейти к построению интегрированной модели, отражающей все существующие связи между подсистемами организации; богатство методов, позволяет моделировать широкий спектр систем; все модели и объекты создаются и хранятся в единой базе проекта, что обеспечивает построение интегрированной и целостной модели предметной области. Выводы по практическому использованию 1. Часто у аналитиков знакомящихся с методологией ARIS возникает чувство, что ARIS может все, она решает все проблемы. Это ошибочное мнение. Методология ARIS решает совершенно конкретный круг задач. Если потребности сильно отличаются от возможностей ARIS (например, сбор требований), то подойдет 49 более специализированное и дешевое решение. ARIS в значительно большей степени предназначен для целей управленческого консалтинга и последующей поддержки решений. Использование ARIS в рамках проекта автоматизации противоречит целям, положенным в основу этой методологии ее создателем. 2. Действительно, если в проекте автоматизации этап анализа вырастает в отдельный консалтинговый этап (например, организации современных схемы управления на основе процессного подхода, в котором цели деятельности определяет совокупность процессов для их достижения, а процессы формируют требования к ресурсам и оргструктуре), то подобный подход является необходимым. А модель, ограничивающаяся описанием бизнес-процессов, будет неполной и не обеспечит потребностей управления. 3. Стоит достаточно осторожно подходить к использованию ARIS. В настоящее время некоторые фирмы используют ARIS при проектировании ИС, но, как правило, используют 1-2 модели, что противоречит методологии. Он нацелен именно на рынок анализа бизнеса и предназначен для больших компаний, внутри которых существуют свои собственные аналитические подразделения. 4. В случае принятия решения о качественной необходимости использования методологии необходимо иметь ввиду, что ARIS нельзя отнести к интуитивно понятным, она требует времени на изучение, на осмысленное применение (вопрос хотя бы в том, что методология содержит больше 100 моделей!). Для успешного применения должны быть разработаны внутренние соглашения о моделировании и документировании 4. Сравнительный анализ подходов к проектированию ИС Очевидно, что выбор методов определяется целями проекта и в значительной мере влияет на весь его дальнейший ход. Рациональный выбор возможен при понимании нескольких аспектов: 1. Целей проекта; 2. Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта; 3. Возможностей подхода с учетом требований п. 2; 4. Особенностей разрабатываемой/внедряемой информационной системы. Например, между сторонниками структурного и ОО-подходов в настоящее время ведутся ожесточенные споры, как и в самом начале эры ОО-подхода. При этом не существует решающих аргументов, доказывающих несостоятельность того или иного из методов. Сравнение подходов должно дать ответы на следующие вопросы: 1. На сколько сам подход и его нотации применимы для того или иного этапа проектирования ИС. 2. Что является критерием для выбора подхода в случае, когда возможно применение более одного подхода (какой подход применить лучше). Т.к. каждый подход регламентируется разработчиками как методология, подходящая для анализа и проектирования, то имеет смысл подробнее остановиться на нотациях. В Таблице 1 представлено сравнение нотация применяемых для анализа ИС. 50 Таблица 1 Сравнительный анализ нотаций eEPC, IDEF, Sequence и Activity diagram № Критерии сравнения eEPC IDEF0 1 Принцип построения Последовательность Принцип выполнения иерархической диаграммы упорядоченности 2 Описание процедуры Объект на Объект на диаграмме диаграмме процесса 3 Входящий документ Используется Стрелка слева, отдельный объект стрелка сверху для описания («документ») IDEF3 Sequence diagram Activity diagram Последовательность Последовательность Последовательность выполнения выполнения выполнения Используется объект для описания («кластер», «технический термин») 5 Исходящий документ, Используется объект для описания информация («документ», («кластер») 7 Используется Исполнитель объект для описания процедуры («позиция», «организационная единица») 8 Используется Используемое отдельный объект оборудование для описания 9 Нет. Может быть Управление отражено только процедурой последовательностью выполнения 10 Нет. Может быть Контроль отражен указанием выполнения входящих процедуры документов 11 Обратная связь по Нет. Может быть управлению/контролю отражена последовательностью выполнения 12 Наглядность модели Модель наглядна и есть возможность использования визуальных образов с последующей конвертацией Стрелка слева, стрелка сверху Стрелка справа 4 Входящая информация Объект на диаграмме Нет (может быть отражен привязкой объекта) Объект на диаграмме Может быть объектом или стрелкой Нет (может быть отражен привязкой объекта) Объект на диаграмме В зависимости от принятого соглашения может быть объектом или стрелкой Может быть объектом или стрелкой Нет (может быть отражен привязкой объекта) Может быть объектом или стрелкой Может быть объектом или стрелкой Нет (может быть отражен в модели только привязкой объектакомментария) Стрелка снизу Нет (может быть отражен привязкой объекта) Стрелка сверху Только логика процесса Используется отдельный объект «Actor» Разграничение зон на диаграмме Только логика процесса Только логика процесса Стрелка сверху Нет Нет. Может быть отражен указанием документов Стрелка сверху Нет Нет. Может быть отражен указанием входящих документов Нет. Может быть отражен указанием входящих документов Модель наглядна, но несколько громоздка Стрелка снизу Модель Модель нечитабельна нечитабельна неспециалистами неспециалистами - Может быть объектом или стрелкой - Нет. Может быть отражен указанием входящих документов Модель очень наглядна Функциональные возможности подходов можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей бизнес-процессов предприятия при анализе и проектировании. Каждый из рассматриваемых подходов имеет свои преимущества и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот, ослабевать. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 позволяет решить эту задачу (хотя данная задача решается довольно редко). С другой стороны, процедура, выполняемая 51 одним сотрудником, может быть более адекватно описана при помощи eEPC ARIS, чем при помощи IDEF0 или IDEF3. Следует подчеркнуть, что модель - не самоцель, это лишь инструмент, именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнеспроцессов. Сравнение структурного, объектно-ориентированного подходов и методологии ARIS приведено на рис. 41 - 42. Рис.41 Анализ структурного подхода Рис.42 Анализ объектно-ориентированного подхода 52 Рис.43 Анализ методологии ARIS ВЫВОДЫ Позиционирование подходов можно провести по отношению к решению задачи моделирования бизнес-процессов на этапе анализа и проектирования (в соответствии с проведенным выше анализом) следующим образом (табл. 2). Таблица 2 Позиционирование подходов относительно типов проектов Подход Тип проекта Типовое проектирование Оригинальное проектирование Смешанное проектирование Структурный подход Объектноориентированный подход ▼∆ Методология ARIS ▼ ∆ ▼∆ ▼ ▼∆ ▼∆ ▼ - анализ ∆ - проектирование Типовое проектирование – этап анализа сводится к сбору информации и утверждении ее полноты и адекватности у Заказчика для настройки системы, для этого замечательно подходят средства объектно-ориентированного подхода. Благодаря наглядности моделей сотрудники Заказчика понимают модели и могут участвовать в их обсуждении (добиться таких результатов при использование нотация структурного подхода практически невозможно). Выбор обуславливается еще и тем, что легко перейти к этапу проектирования и инструмент будет единый. Проектирование непосредственно проработка настроек системы, т.е. реализация бизнес-процессов Заказчика в рамках внедряемой системы. Использование структурных нотаций или 53 моделей АРИС нецелесообразно и избыточно. Примером такого проекта может служить внедрение системы «Галактика» или «1С». Оригинальное проектирование – этап анализа имеет классический вид, необходимо качественное и полное построение бизнес-процессов организации с проведением их реинжиниринга. Для правильного и точного выявления и формализации требований хорошо подходят нотации структурного подхода и ARIS. Выбор будет обуславливаться: 1. Потребностями и целями проекта (либо это комплексное обследование и моделирование с масштабными преобразованиями, либо качественный сбор информации и небольшие изменения), аспектами анализа и требованиями к информации; 2. Предпочтениями аналитиков и наличием инструментальных средств. Главной целью формирования моделей ИС является обеспечение перехода от моделей описания организации к системе моделей, описывающих конкретные компоненты проекта, такие как приложения, базы данных, при котором обеспечивается отображение задач организации в функции и компоненты ИС (этап проектирования ИС). Этап проектирования в обоих случаях основан на использовании языка UML и наиболее удачной методики Лармана. Смешанное проектирование – новые модули разрабатываются по схеме оригинального проектирования, в остальном - типового проектирования. Проведенный анализ сильных и слабых сторон структурного, объектно-ориентированного подходов и методологии ARIS является основой технологии проектирования ИС с использованием CASE – технологий. Предложенная схема использования подходов к проектированию ИС обеспечивает снижение сложности процесса создания ИС, существенно повышает эффективность проекта и помогает избежать ненужных, избыточных действий благодаря оптимальному выбору инструментов в зависимости от типа проекта. 54 ЛЕКЦИЯ №8 ТЕМА: Бизнес-процессы и информационные технологии: классификация информационных систем, современные подходы к построению корпоративной информационной системы (КИС) (обзор рынка систем, основной функционал, факторы риска при внедрении систем класса ERP, критерии выбора ERP). История развития современных ERP-систем MPS «Master planning schedule» Первым стандартом управления бизнесом стал MPS «Master planning schedule», хорошо известный под названием «объемно - календарное планирование». Данный стандарт является базовым практически для всех планово - ориентированных методологий. Стандарт основан на формировании плана продаж («объем», с разбивкой по календарным периодам - отсюда - обьемно-календарное), по которым затем формируется план пополнения запасов (за счет производства или закупки) и оцениваются финансовые результаты по периодам (в качестве которых используются периоды планирования или финансовые периоды). Одной из наиболее сложных проблем, возникавших при формировании заказа была проблема прогнозирования необходимого объема и срока поставки. Прогноз объемов и сроков поставок необходим для прогнозирования спроса на длительное время вперед, при этом необходимо учитывать длительность (а часто и сезон) производства и потребности в складских площадях. MRP \ CRP «Material \ Capacity Requirements Planning» Методология планирования материальных \ производственных ресурсов появилась в середине 60-х годов. Сущность методологии MRP состоит в определении конечной потребности в ресурсах по данным объемно-календарного плана производства. Ключевым понятием данных методологий является понятие «разузлование», то есть приведение древовидного состава изделия (BOM - Bill of material) к линейному списку, по которому возможно планирование потребности и собственно формирование заказа расходных и комплектующих материалов или планирование производства для внутреннего потребления. Планирование потребности в производственных мощностях (CRP) имеет близкие функциональные задачи, но вместо единого понятия состава изделия оперирует такими неоднородными понятиями, как «обрабатывающий центр», «машина», «рабочие ресурсы», ввиду чего технически реализация CRP более сложна. FRP «Finite \ Finance Requirements Planning» Под данной аббревиатурой скрываются две совершенно различные методологии первая - планирование производственных ресурсов в условиях ограниченных мощностей, вторая - планирование финансовых ресурсов. Ни та ни другая не имеют статуса фактического стандарта, в основном ввиду того, что такого рода планирование достаточно специфично для конкретного предприятия и конкретной реализации. В дальнейшем аббревиатура FRP будет использоваться для обозначения методологии планирования финансовых ресурсов. 55 MRP II «Manufacturing Resource Planning» Методология планирования, интегрирующая MRP и CRP, появилась в конце 70-х годов. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана (closed loop). Использование данной методологии как правило, также подразумевает использование MPS и FRP, правда без их интеграции в «динамическую систему». ERP «Enterprise Resource Planning» Автоматизированные системы стандарта ERP выполняют функции, предусмотренные стандартами MPS-MRP\CRP-FRP-SIC. Важным дополнением внесенным по сравнению с механическим соединением данных методологий является возможность динамического анализа и динамического изменения плана по всей цепочке планирования после подготовки «планового черновика». Таким образом достигается возможность более точного определения причин возникновения «исключительных ситуаций» и управления плановыми компонентами. Конкретные возможности данной методологии существенно зависят от программной реализации. CSRP (Customer Synchronized Resource Planning) Самый последний по времени стандарт, появившийся в середине 90-х годов, охватывает в контуре планирования также и цикл взаимодействия с клиентами, начиная с оформления заказа с возможностью его отслеживания, конфигурирование продукта и даже технологии его производства, поддержку заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то стандарт CSRP вышел за пределы отельного предприятия и включил в понятие «планирование ресурсов» полный жизненный цикл товара от проектирования будущего изделия до гарантийного и сервисного обслуживания после продажи. 56 Методологии управления ресурсами на предприятии Планирование потребности в материалах (MRP) Управление материальными ресурсами - одна из важных областей планирования. Успешное функционирование промышленного предприятия напрямую зависит от того, насколько хорошо и ритмично оно снабжается сырьем или комплектующими, насколько рационально используются складские площади, и, наконец, насколько тесно объемы выпуска связаны с заказами клиентов или потребностью рынка. Изменение оптимального соотношения любой из этих составляющих приводит к тем или иным проблемам: перебои с поставками сырья ведут к простоям оборудования и снижению выпуска продукции; поступление большего, чем необходимо, количества материалов может повлечь необоснованные потери в виде избыточных запасов на складах (обычно такие запасы называют "омертвленными затратами"). Проблема наличия необходимых материалов и комплектующих в нужное время, в нужном месте и в нужном количестве особенно актуальна для массовых сборочных производств, где простои конвейера недопустимы. Именно под такие производства и разрабатывалась методология MRP и соответствующие программные решения. Методология MRP служит для реализации следующих целей: минимизировать запасы на складах сырья и готовой продукции; оптимизировать поступление материалов и комплектующих в производство и исключить простои оборудования из-за не прибывших вовремя материалов и комплектующих. В соответствии с этим, закупки материалов и комплектующих всего отрезка планирования автоматически распределяются по плановым периодам (например, дням), причем объем и время закупок рассчитываются так, чтобы в каждый плановый период на предприятие поступало именно столько материалов и комплектующих, сколько требуется производству в этом плановом периоде. Остановимся подробнее на алгоритме MRP-планирования. Для работы MRPмодуля требуются следующие входные данные: Основной производственный план-график (объемно-календарный план, Master Planning Schedule - MPS) - документ, в котором расписано, сколько единиц конечного изделия будет производиться в каждый плановый период отрезка планирования. Данные о состоянии запасов (книга учета запасов, Inventory Status File) - документ, максимально полно раскрывающий информацию о каждой учетной единице сырья, материалов, комплектующих, конечных изделий, включающую: o общее описание - идентифицирующий код, характеристику, размер, вес и пр.; o данные о запасах: единица запаса, расположение, размер запаса, статус (например, находится на руках, на складе, в текущих заказах), оптимальный запас, страховой запас и пр.; o данные по закупкам и продажам для сырья, материалов и комплектующих: единица закупки/продажи, основные поставщики/покупатели, цена, время доставки, реквизиты поставщиков/покупателей, дополнительная информация (например, возможные задержки поставок); o данные по производству для полуфабрикатов и конечных изделий: размер партии, длительность производственного цикла. Спецификация состава изделия (Bill of Materials File - BOM) - документ, содержащий: 57 перечень сырья, материалов и комплектующих, необходимых для производства конечного изделия, с указанием нормативов по их использованию; o иерархическое описание структуры конечного изделия. Результатами работы MRP-модуля являются следующие документы. График заказов на закупку/производство материалов и комплектующих (Planned Order Schedule) - документ, расписывающий, какое количество сырья, материалов, комплектующих должно быть заказано в каждый плановый период в течение срока планирования. Этот документ определяет внутрипроизводственный план сборки комплектующих и план внешних закупок. Изменения к графику заказов на закупку/производство материалов и комплектующих (Changes in planned orders) - документ, содержащий корректировки ранее спланированных заказов на закупку/производство материалов и комплектующих. Обычно входные и выходные данные MRP-модуля представляются в виде таблиц базы данных. o Вход Выход 1. Основной производственный график 2. Данные запасов о план- состоянии MRPцикл 1. График заказов на закупку/производство материалов 2. Изменения к графику заказов на закупку/ производство материалов 3. Спецификация состава изделия Укрупненно цикл MRP-планирования состоит из следующих шагов. 1. Составляется таблица общих потребностей в материалах и комплектующих. Последовательность ее создания такова. o Древовидная структура состава изделия разворачивается в линейный список материалов и комплектующих. o Из книги учета запасов переносятся данные о материалах и комплектующих, необходимых для производства конечного изделия, и, в частности, данные о времени выполнения заказа на их поставку/производство. o Переносятся плановые показатели выпуска конечного изделия из основного план-графика производства. o По каждому материалу и узлу для каждого планового периода рассчитывается общая производственная потребность в этом материале/узле; при этом используются данные состава изделия (количество каждого материала/узла, необходимое для производства конечного изделия или промежуточного узла) и информация о времени поставки/производства материалов и комплектующих. 2. По каждому материалу на каждый плановый период считается чистая потребность в этом материале. При этом используются данные о состоянии запасов. Чистая потребность считается по формуле: чистая потребность = общая потребность – (текущие запасы + активные заказы страховой запас) В идеале MRP-система не должна создавать страховых запасов. Однако в реальности случаются 58 непредвиденные и неустранимые срывы поставок материалов. Для поддержания процесса производства в подобных ситуациях создают страховой запас. Его размер определяется заранее компетентными лицами и зависит от конкретных условий производственного процесса. 3. По ненулевым чистым потребностям формируется график заказов на закупку/производство материалов и комплектующих. При его создании учитывается время выполнения каждого заказа. 4. Просматриваются заказы, сгенерированные ранее текущего периода планирования. В случае необходимости система пересчитывает сроки и размер заказа и вносит корректировки в сформированный ранее план-график закупок. Эти изменения автоматически регистрируются в базе данных о состоянии запасов (поскольку создание, отмена или модификация заказа влияет на статус соответствующего ему материала). Данная схема работы MRP-цикла очень упрощена. В реальности необходимо учитывать огромный спектр особенностей конкретного производственного процесса (например, широкий ассортимент производимых товаров, конструктивную сложность конечных изделий, территориальную разбросанность складов, регулярные сбои поставок комплектующих). Поэтому MRP-системам приходится просчитывать огромное количество информации, и длительность MRP-цикла может измеряться часами даже на современном уровне развития вычислительной техники. Даже такой поверхностный обзор методологии MRP обнаруживает ее "узкие" места: Отсутствие контроля выполнения плана закупок и механизма корректировки этого плана в случае возникновения ситуаций, мешающих его нормальному исполнению. Даже самый совершенный график закупок материалов не может гарантировать, что, например, служащие чего-нибудь в нем не напутают, или что в нужный момент на счету у предприятия будут деньги для оплаты поставок. Поэтому сгенерированные MRP-модулем заказы могут оказаться нереализованными, что потребует корректировки сформированного им плана закупок. Но ни фиксация сбоев в выполнении плана поставок, ни соответствующая корректировка плановых заданий в MRP-модуль не заложены. Запускать MRPцикл заново каждый раз при обнаружении нарушений неэффективно, так как это занимает много времени и требует больших ресурсов. Ограниченный учет производственных факторов. Одно лишь детальное планирование материальных потребностей не может обеспечить эффективное выполнение производственного плана. Необходимо еще оценить, хватит ли для этого производственных мощностей, трудовых и финансовых ресурсов. Помимо этого, для управления себестоимостью продукции (одна из целей разработки MRPметодологии) одного материального учета мало: нужно проанализировать и другие факторы производственного процесса. Методология планирования материальных потребностей в замкнутом цикле (Closed Loop MRP) является модификацией MRP-методологии. Термин "в замкнутом цикле" отражает основную особенность новой методологии - осуществление обратной связи по состоянию выполнения сформированных планов. Помимо базовой функции планирования потребности в материалах, Closed Loop MRP-модули содержат дополнительную функцию - контроль фактического состояния производства и выполнения заказов на закупку материалов и комплектующих. Если анализирующая подсистема модуля выявила значительные нарушения плановых показателей, она инициирует внесение корректив в ранее принятые планы. Модификация старых планов выполняется в режиме "MRP-цикл с учетом чистых изменений". Его отличие от обычного MRP-цикла заключается в том, что обрабатываются только те изменения, которые появились со времени последнего прогона MRP. Это позволяет быстро привести график закупок в соответствие с реальной ситуацией. Методология CRP (Capacity Requirements Planning) возникла в результате распространения принципов MRP на более широкий, чем управление материалами, круг 59 задач. Основная задача методологии CRP - проверить выполнимость основного планграфика с точки зрения имеющегося оборудования и, если он выполним, оптимизировать загрузку производственных мощностей. Для работы CRP-модуля требуется следующая входная информация. Составленный MRP-модулем график заказов на закупку/производство материалов и комплектующих (Planned Order Schedule). Данные об имеющихся мощностях - документ, максимально полно раскрывающий информацию о каждом рабочем центре, в том числе: общую информацию - идентифицирующий код, название, описание структуры рабочего центра, его мощность и пр.; состав производственного оборудования - список машин и механизмов данного рабочего центра с указанием идентифицирующих кодов, обслуживающего персонала, производственных операций, выполняемых в привязке к этим машинам и механизмам, и нормативной трудоемкости этих операций. Технологическая схема изготовления конечного изделия (Routing Plan) - документ, описывающий все операции, необходимые для изготовления конечного изделия, с указанием для каждой производственной операции: содержания операции; рабочего центра, в котором она должна выполняться; оборудования этого рабочего центра, используемого для выполнения операции; времени операции в человеко-часах, включая вспомогательное время (например, на переналадку оборудования). Механизм работы CRP-модуля принципиально похож на механизм MRP. Вместо основного план-графика производства в нем используется график заказов на закупку/производство материалов и комплектующих, поступающий из MRP-модуля. Роль спецификации состава изделия играет технологическая схема изготовления конечного изделия, каждый уровень сборки конечного изделия характеризуется набором операций, необходимых для изготовления определенного узла. На основе анализа исходной информации CRP-модуль считает необходимые для выполнения производственного планграфика мощности, сравнивает их с имеющимися на предприятии и, в зависимости от результата, формирует на выходе следующие данные: Величину превышения/недостатка производственных мощностей. В этом случае плановикам следует изменить производственную программу и повторить процесс. Если мощностей хватает, автоматически составляются следующие документы: o План загрузки производственных мощностей - документ, который показывает для каждой единицы производственных мощностей степень ее загрузки в каждый плановый период. o План загрузки рабочего персонала - документ, аналогичный предыдущему. Определяет величину занятости каждого производственного рабочего в каждый плановый период. o План-график производственных работ - документ, определяющий последовательность и характеристику операций, совершаемых на каждой производственной единице в каждый плановый период. По этому документу впоследствии строится вся работа предприятия по производству конечного изделия. Ниже приведена типовая структура представляемой в нем информации для каждой производственной единицы. Следует отметить, что, несмотря на близость плановых механизмов, техническая реализация CRP гораздо сложнее, чем реализация MRP. В CRP требуется учесть большее количество параметров: в MRP каждому уровню сборки конечного изделия сопоставляются однородные характеристики - материалы и комплектующие, тогда как в CRP каждому уровню изготовления конечного изделия сопоставляются неоднородные 60 характеристики - операции (которые различаются, помимо содержания, рабочими центрами, машинами, трудовыми ресурсами, привлекаемыми для их совершения). При этом окончательный результат работы CRP содержит, помимо оценки необходимых мощностей, распределение работ по времени. Это очень ресурсоемкая вычислительная задача. Планирование производственных ресурсов (MRP II) В 80-х годах базовые принципы методологий MRP, CRP и Closed Loop MRP были объединены в единую методологию планирования - MRP II (Manufactory Resource Planning,). Методология MRP II описывает сквозное планирование и управление цепочкой "сбыт - производство - склад - снабжение". В отличие от предшествующих методологий планирования, она фокусируется на оперативном планировании и управлении всем производственным процессом, а не отдельными его фрагментами. Методология MRP II нацелена на решение следующих основных задач : Сформировать основной производственный план-график (объемно-календарный план, Master Planning Schedule - MPS), расписывающий, что и в каком количестве будет производить предприятие в каждый период отрезка планирования. С одной стороны, этот план должен максимально учитывать имеющийся портфель заказов и маркетинговые исследования спроса, чтобы своевременно удовлетворить потребности клиентов, но и не производить излишек продукции, который впоследствии долго пролежит на складе, дожидаясь своего покупателя. С другой стороны, составленный план должен быть выполним при текущей структуре активов компании (производственные мощности, персонал, финансовое обеспечение). Достижение компромисса между удовлетворением рыночного спроса и осуществимостью такой производственной программы - очень важная задача, и она успешно решается с использованием методологии MRP II. Составить оперативные планы, раскрывающие реализацию утвержденной производственной программы: план-график производственных работ, план-график закупок сырья и материалов, план-график использования денежных средств. По этим планам впоследствии строится вся производственная деятельность предприятия. Однако MRP II увеличивает ценность этих планов тем, что в рамках данной методологии решается важная задача оптимизации потребления ресурсов. А именно, при составлении планов преследуется цель оптимального распределения потребляемых ресурсов (денежных средств, материалов, производственных мощностей) по всему отрезку планирования. Необходимо, с одной стороны, обеспечить выполнение основного план-графика производства и бесперебойность производственного процесса, и, с другой стороны, предотвратить создание излишних материальных запасов. Достижение такой цели требует интегрированного планирования потребности в ресурсах, т. е. планирования потребностей на уровне всех подразделений, участвующих в производственном процессе (производственных, складских, снабженческих и сбытовых), с рассмотрением сложной системы взаимосвязей между этими подразделениями. Реализация методологии MRP II в конкретной информационной системе предполагает наличие обратной связи, информирующей о качестве выполнения сформированных планов и позволяющей, чтобы при необходимости, внести коррективы в эти планы. Первоначально методология MRP II разрабатывалась для сборочных (дискретных) производств. Классическим примером дискретного производства является машиностроение. Не вдаваясь в детали, дискретное производство можно определить так: это производство по сборке конечного изделия, основанное на иерархическом описании 61 состава изделия. Впоследствии аналогичные принципы и методы планирования были разработаны и для других типов производств. В работе MRP II-системы четко выделяются три этапа. Первые два предполагают реализацию методологии MRP и заканчиваются утверждением планов. Последний же, протекающий параллельно с реальным производственным процессом, включает контроль выполнения сформированных планов и оперативное, по мере необходимости, внесение поправок в ход производства: На основе заказов независимого спроса формируется основной производственный планграфик. По данным производственного плана, исследований рынка, прогноза спроса, портфеля заказов на продукцию составляется предварительный план-график выпуска конечных изделий. Запускается процедура RCCP (Rough Cut Capacity Planning, предварительное планирование мощностей) - быстрой проверки выполнимости составленного плана с точки зрения имеющихся мощностей и существующей технологии производства. Эта процедура предполагает создание потока заказов зависимого спроса между подразделениями предприятия, задействованными в производственном процессе, и проверку выполнимости этих заказов на заранее выделенных критических участках производства (т. е. в рабочих центрах, которые лимитируют или же определяют сменный выпуск изделий). Если предварительный план-график выпуска конечных изделий признается реально осуществимым, то он становится основным планом выпуска. В противном случае в предварительный план-график вносятся изменения, и он подвергается повторному тестированию с помощью процедуры RCCP. 1. На основе принятого производственного план-графика планируются потребности в материалах, мощностях и финансовых ресурсах. Запускается стандартный MRP-цикл, основным результатом которого является план-график заказов на закупку/производство материалов и комплектующих. Запускается CRP-цикл, который дает план-график производственных работ, описывающий всю дальнейшую производственную деятельность. По этим двум документам оценивается потребность в финансах (Financial Requirements Planning - FRP) для осуществления производственной деятельности. То есть рассчитываются операционные расходы на закупку материалов, производственные нужды, зарплату производственному персоналу и т. д., и эти расходы распределяются по всему горизонту планирования. 2. В соответствии со сформированными план-графиками начинается реальная производственная деятельность. При этом MRP II-система осуществляет оперативное управление производственным процессом: контролирует выполнение плановых заданий и при необходимости вносит коррективы в действующие планы. Выполнение плановых заданий оперативно регистрируется в MRP II-системе. Система, на основе сравнения фактических и нормативных показателей, анализирует протекание хозяйственного процесса. Аналогично система отслеживает потребление производственными единицами материалов и комплектующих и регистрирует отклонение фактических и нормативных показателей потребления по каждой производственной единице. Это позволяет быстро диагностировать ситуацию, когда производственная единица не развивает плановой производительности из-за недостаточного снабжения материалами. Анализируя ход производственного процесса, MRP II-система ежедневно формирует сменные задания для рабочих центров (Operation lists), которые отсылаются руководителям рабочих центров. Сменные задания отражают 62 последовательность проведения рабочих операций над сырьем и комплектующими на каждой единице производственных мощностей и длительность этих операций. В отличие от план-графика производственных работ, формируемого CRP-модулем, в этих цеховых заданиях автоматически учитывается уменьшение/увеличение скорости работы производственной единицы: сменные задания могут содержать как запоздавшие по каким-либо причинам производственные заказы (уменьшение скорости обработки), так и производственные заказы, запланированные на последующие плановые периоды (увеличение скорости обработки). Точно так же, формируя скорректированные ежедневные задания на закупку/поставку сырья и комплектующих, MRP II-система регулирует работу снабженческих, сбытовых и складских структур предприятия. Изначально методология MRP II и MRP II-системы разрабатывалась для сборочных (дискретных) производств, и не отвечала специфике других типов производств. Попытки "скорректировать" лежащую в ее основе математическую модель для применения, например, в процессном производстве, приводили к таким нереальным результатам, как отрицательные времена производства и отрицательные потребления ресурсов. Этот подход не стал эффективным в связи с принципиальными различиями дискретных и процессных производств. Поэтому для процессного и проектного производств были созданы оригинальные математические модели и алгоритмы решения задачи планирования ресурсов, что явилось основой создания MRP II-систем, ориентированных на "недискретные" типы производства. Планирование корпоративных ресурсов (ERP) Одной из ярких черт современной экономики являются интенсивные процессы интеграции участников рынка, и, как следствие, эти процессы вызвали существенные изменения во внутреннем устройстве компаний: усложнение организационной структуры: o наличие в составе компании автономных предприятий со своей собственной логистической организацией; o непростая система производственных и административных связей между этими автономными объектами; географическая разбросанность производственных, складских и/или сбытовых подразделений; сосуществование производств различных типов; диверсификация деятельности; наличие международной сети поставщиков комплектующих и услуг; усложнение логистических цепочек поставок продукции как внутри, между автономными подразделениями компании, так и вовне, между компанией и ее дистрибуторами и заказчиками. Главная цель концепции ERP - распространить принципы MRP II на управление современными корпорациями. Концепция ERP представляет собой надстройку над методологией MRP II. Не внося никаких изменений в механизм планирования производственных ресурсов, она позволяет решить ряд дополнительных задач, связанных с усложнением структуры компании. Концепция ERP до сих пор не стандартизована. Когда возникает вопрос об отнесении конкретной информационной системы управления к классу развитых MRP IIсистем или к классу ERP, специалисты расходятся во мнениях, поскольку выделяют различные критерии принадлежности системы классу ERP. Однако, суммируя различные точки зрения, можно указать основные черты, которыми должны обладать ERP-системы: универсальность с точки зрения типов производств; 63 поддержка многозвенного производственного планирования; более широкая (по сравнению с MRP II) сфера интегрированного планирования ресурсов; включение в систему мощного блока планирования и учета корпоративных финансов; внедрение в систему средств поддержки принятия решений. Возможность планирования для всех типов производства в рамках одной системы Даже на обычном предприятии (не говоря уже о корпорации) могут сосуществовать производства различных типов - проектное, дискретное и непрерывное. Для поддержки планирования и управления всем предприятием в целом, информационная система должна "уметь" работать с каждым из этих типов производств. Поэтому системы класса ERP содержат набор модулей, каждый из которых специализирован на определенном типе производства. Обеспечение многозвенного производственного планирования Большие производственные объединения, распределенные территориально, могут состоять из обособленных структурных подразделений или филиалов (звеньев). Каждый филиал, как правило, имеет отдельный законченный производственный процесс. Однако зачастую подразделения связаны между собой цепочкой поставок некоторых единиц продукции. Это усложняет процесс планирования деятельности как отдельных подразделений, так и всего производственного объединения. Чтобы предотвратить простои и перегрузки отдельных производств из-за не поставленных вовремя деталей, план-графики закупок/производства различных производственных подразделений компании должны быть согласованы между собой. Логика работы заложенных в ERP-системы средств агрегирования планов проста. Сначала формируются собственные планы закупок/поставок и производства для каждого предприятия-звена единой организационной структуры. При этом в план-графиках закупок и производства по каждой номенклатурной единице, входящей во внутрипроизводственную сеть поставок, указываются источник (потребитель) и приоритетность поставки этой единицы. Затем создается многозвенный (агрегированный) план. Для этого ERP-система обобщает потребности предприятий-звеньев в номенклатурных единицах, входящих в сеть внутренних поставок, и генерирует производственные планы для каждого звена с учетом поставок между звеньями. Прежде чем представить эти планы для утверждения, система проводит сценарную оценку их выполнимости. Как и в обычных MRP II-системах, оценка выполнимости планов происходит путем создания системой потока заказов зависимого спроса на уровне всего производственного объединения. При выявлении критических состояний планы корректируются, и лишь затем поступают на утверждение. Расширение сферы интегрированного планирования ресурсов В классических MRP II-системах интегрированное планирование ресурсов охватывало лишь производственные, складские, снабженческие и сбытовые подразделения предприятия. Действия других тесно связанных с производственным процессом подразделений и служб (например, ремонтных, транспортных) не вовлекались в планирование. Точно так же за кадром оставались проектные работы. ERP-системы позволяют вовлечь в сферу интегрированного планирования ресурсов все подразделения предприятия, так или иначе эти ресурсы использующие. Это позволяет достичь оптимизации бизнес-операций предприятия, а также координации действий всех служб и подразделений для обеспечения их эффективной работы. В связи с этим, в ERP-системах появляются следующие дополнительные подсистемы. 64 Планирование и управление реализацией производственных проектов. В этой подсистеме ведется анализ проекта (разработка его структуры, выделение подпроектов, разбиение подпроектов на отдельные работы), формирование сетевых графиков работ, планирование материальных и трудовых ресурсов, оборудования, финансовых затрат для выполнения этих работ, управление ходом их выполнения. Планирование работы сервисно-технических служб. Подсистема позволяет планировать ресурсы и оптимизировать выполнение работ по техническому обслуживанию производственных объектов. Подсистема оказывает сильное влияние на работу модуля планирования производства. Если проводится аварийный или плановый ремонт некоторой единицы производственных мощностей, то подсистема должна оповестить модуль планирования производства о блокировке данной единицы производственных мощностей на определенный период и указать на этот период альтернативный производственный маршрут. Планирование и управление распределенными ресурсами (Distribution Resources Planning). Такая подсистема предоставляет возможность работать со сложной многозвенной структурой сбытовых подразделений и складов. В частности, в ее компетенцию входит и планирование работы транспортных служб. С помощью подсистемы можно: o минимизировать транспортные затраты на доставку сырья и комплектующих; o организовать сбалансированное распределение материалов и продукции по складам компании; o выбрать оптимальные транспортные маршруты при проведении межскладских перемещений (когда есть несколько складов) или перемещений между сбытовыми подразделениями (когда есть сеть дилерских организаций). Планирование и управление послепродажным и специальным обслуживанием. Как следует из названия, подсистема предназначена для управления всеми видами сервисных услуг. Здесь нужно отметить важную деталь. Во многих современных MRP II-системах появляются подсистемы "Проект", "Сервис", "Транспорт" и т. д. Однако, хотя в этих подсистемах и ведется учет затрат и доходов, бюджетирование, зачастую в них нет необходимой для ERP функциональности по созданию потока заказов, порождающей интегрированное планирование потребностей в ресурсах и мощностях в масштабах всего предприятия. Планирование и учет корпоративных финансов Реализация в ERP-системах поддержки планирования ресурсов разветвленной корпорации влечет необходимость усиления финансового блока, реализации управления сложными финансовыми потоками и возможности корпоративной консолидации. Поэтому в ERP-системы входят мощные системы управления корпоративными финансами, характеризующиеся следующими особенностями: поддержка многозвенной структуры управления - возможность анализировать финансовые данные как на уровне отдельных подразделений-звеньев, так и на уровне всей компании; гибкость - поддержка нескольких часовых поясов, языков, национальных валют и систем бухгалтерского учета и отчетности; полнофункциональный аппарат ведения бухгалтерского и управленческого учета; ведение финансового планирования; ведение расчетов с дебиторами и кредиторами; 65 наличие аппарата для отслеживания возвращаемости кредитов, включающего ведение истории отношений с кредиторами, анализа состояния их дел, поиск сведений о них; полная интеграция с данными других подсистем ERP-систем. Включение в системы мощных средств поддержки принятия решений Сама по себе ERP-система не является инструментом для принятия управленческих решений, она лишь поставляет необходимую для этого информацию. Реальную же поддержку принятия управленческих решений оказывают специальные аналитические средства, вводимые в ERP-системы (обычно эти средства называют OLAP – On-line analytical processing). Приведем некоторые возможности систем поддержки принятия решений: отслеживание эффективности работы различных участков и служб для выявления и устранения слабых звеньев, а также для совершенствования структуры бизнеспроцессов и организационных единиц; анализ деятельности отдельных подразделений; агрегирование данных из различных подразделений; анализ показателей различных направлений финансово-хозяйственной деятельности предприятия для выделения перспективных и убыточных направлений бизнеса; выявление тенденций, развивающихся как внутри предприятия, так и на рынке. Сразу следует отметить, что и для MRP II-систем, и для ERP-систем основным является производство. Они, безусловно, развиваются в связи с запросами рынка: добавляются новые функциональности, решения переносятся на новые технологические платформы. Однако производственные подсистемы остаются центральными для рассматриваемых систем, и различия между MRP II- / ERP-системами лежат именно в области планирования производства. А связаны эти различия с глубиной реализации планирования, что обусловлено ориентацией этих систем на различные сегменты рынка. ERP-системы создаются для больших многофункциональных и территориально распределенных производственных корпораций. MRP II-системы ориентированы на рынок средних предприятий, которым не требуется вся мощность ERP-систем. Собственно, различие MRP II- и ERP-систем понятно уже из их названия: с одной стороны, планирование корпоративных ресурсов (Enterprise Resources Planning), с другой планирование производственных ресурсов (Manufacture Resources Planning). Существенные же отличия ERP от MRP II можно выразить следующей формулой: ERP = MRP II + реализация всех типов производства + интегрирование планирования ресурсов по различным направлениям деятельности компании + многозвенное планирование Планирование ресурсов, синхронизированное с покупателем (CSRP) MRP II / ERP – системы ориентированы прежде всего на производственную эффективность предприятия, однако время не стоит на месте, и все большая конкуренция во всех сферах производства требует новых решений для увеличения, или даже сохранения уровня прибыли. При одинаковом качестве и ценах, какого производителя предпочтет покупатель? Того, что предоставляет товары/услуги, наиболее отвечающие специфическим требованиям покупателя. Задача производителей, достигнувших производственной эффективности заключается в том, чтобы с прибылью для себя предоставить широкий выбор товаров, которые смогут изменяться также быстро, как и предпочтения покупателей. Способность производителей совместить индивидуальные покупательские 66 предпочтения с производством и системой планирования станет решающим фактором на рынке в ближайшие десять лет. Несмотря на большое количество достоинств, с точки зрения приобретения конкурентного преимущества на рынке ERP-системы обладают и некоторыми недостатками: Внутренняя сфокусированность на управлении производством, учете, планировании; Запаздывающее реагирование на изменения рынка; Эффективность производственных операций может быть скопирована конкурентами. Наиболее мощными инструментами управления производством в этом десятилетии будут те, которые будут построены на твердом фундаменте ERP, будут фокусироваться на интеграции с покупателями. Система планирования производства этого десятилетия должна иметь два фокуса - на производственной эффективности и на создании покупательской ценности. Эта новая парадигма планирования и есть планирование ресурсов, синхронизированное с покупателем - CSRP. Для внедрения CSRP необходимо: Оптимизировать производственную деятельность (операции), построив эффективную производственную инфраструктуру на основе методологии и инструментария ERP; Интегрировать покупателя и сфокусированные на покупателе подразделения, с основными планирующими и производственными подразделениями; Внедрить открытые технологии, чтобы создать технологическую инфраструктуру, которая может поддерживать интеграцию покупателей, поставщиков и приложений управления производством. Остановимся подробнее на двух последних аспектах. Интеграция покупателя с планирующими и производственными подразделениями Синхронизация покупателя и отделов организации, ориентированных на работу с покупателем, с исполнительным и планирующим центром компании обеспечивает способность выявлять благоприятные возможности для создания различий, поддерживающих конкуренцию. Производители, взаимодействующие не только с производством, но и с покупателем, могут создавать преимущества путем развития систематического подхода к вопросам: какие продукты производить какие услуги предлагать на какие новые рынки нацеливаться В ERP-системах критическая информация о покупателе и знание рынка удалены от основной системы планирования бизнеса. Не существует конкретного и действенного способа использовать знания о покупателе во всей организации. CSRP - это первая бизнес методология, которая интегрирует деятельность предприятия, ориентированную на покупателя, в центр системы управления бизнесом, сдвигая фокус предприятия с планирования от потребностей производства к планированию от заказов покупателей. Деятельность по производственному планированию не просто расширяется, а удаляется и заменяется запросами покупателей, переданными из подразделений организации, ориентированных на работу с покупателями. CSRP переопределяет практику бизнеса, фокусируя ее на рыночной активности, а не на производственной деятельности. Бизнес-процессы, протекающие в компании синхронизируются с деятельностью покупателей: Переопределяется процесс обработки заказов. Обработка заказов расширяется и вместо простой функции ввода заказа, интегрирует функции продажи и маркетинга с покупателем. Обработка заказов не начинается с собственно заказа, она начинается с покупателя или даже с перспектив продажи. 67 Продавцы больше не размещают заказы. Они совместно с покупателем формируют заказы, определяя потребности покупателя, которые динамически переводятся в требования к продуктам и их производству. Технология конфигурирования заказов позволяет проверить его выполнимость до его размещения. Лидирующие системы управления контактами интегрируются с процессом создания заказов и производственного планирования, чтобы предоставить информацию о требуемых ресурсах, до того как заказ будет размещен. Тенденции рынка, спрос на продукты и информация о предложениях конкурентов связываются с ключевыми бизнес-процессами. Статичные ценовые модели заменяются на инструмент ценообразования, который позволяет при необходимости определить стоимость каждого продукта для каждого покупателя. Приложения поддержки пользователей интегрируются с ключевыми приложениями планирования, производства и управления. Критическая информация о покупателях и товарах заранее поставляется подразделениям, отвечающим за производство, продажи, исследования и развитие, а также другим подразделениям. Технологии, основанные на Web, расширяют поддержку покупателей, делая ее удаленной, круглосуточной, самостоятельно настраиваемой. Ключевые исполнительные системы автоматически изменяются, увеличивая возможность быстрее предоставлять покупателям ответы и услуги. Центры поддержки покупателей приобретают дополнительную функцию продажи. Интеграция с продажами, обработкой заказов и управлением обеспечивает знания и инфраструктуру для превращения поддержки покупателей в деятельность по продаже, обеспечивая канал для продвижения новых и сопутствующих продуктов и услуг. Непосредственная интеграция с информацией о конфигурации заказов позволяет производственным подразделениям увеличить целостность процесса планирования путем снижения количества повторной работы и снижения числа перерывов в работе. Усовершенствование производственного планирования дает возможность производителям обеспечить лучшую оценку сроков поставок и осуществить поставку вовремя. Производственное планирование теперь позволяет оптимизировать операции на основе действительных покупательских заказов, а не на прогнозах или оценках. С доступом в реальном времени к точной информации о заказах покупателей, подразделения планирования могут динамически изменять группирование работ, последовательность исполнения заказов покупателей, приобретения и заключения субконтрактов с целью улучшения обслуживания покупателей и снижения стоимости. Требования покупателей к продукту могут передаваться непосредственно от покупателя к субконтрактору или поставщику, устраняя ошибки и задержки, которые встречаются при трансляции заказов покупателей в заказы на покупку. Изменения в заказе покупателя могут приводить к автоматическим изменениям в заказах поставщикам, уменьшая количество повторной работы и задержки. Качество продуктов и правильность заказа основных комплектующих могут быть значительно улучшены, а также уменьшены циклы их доставки. При использовании модели бизнеса CSRP, традиционные бизнес-процессы пересматриваются в направлении к обслуживанию покупателей и создании продуктов удовлетворяющих их потребности. Внедрение приложений CSRP подталкивает руководителей предприятия к изменению. CSRP позволяет построить двунаправленный поток информации между покупателем и производителем. 68 Внедрение открытых технологий Открытые технологии делают CSRP практичным. Способность интегрировать множество технологий с множеством приложений критичны для успеха CSRP. В настоящее время стало возможным собрать отдельные приложения, разработанные различными производителями в одно унифицированное приложение для управления производством. Для производителей (предприятий) появилась возможность дать служащим те технологии, которые могут удовлетворить специфические требования их бизнеса и, в то же время, могут быть интегрированы с основными приложениями предприятия. Производство, управление, продажи, обслуживание покупателей, техническое обслуживание и другие, ориентированные на покупателя бизнес функции, могут выполняться соответствующими подразделениями с использованием программного обеспечения, разработанного специально для этих подразделений, при этом эти приложения могут предоставлять и получать критичную для бизнеса информацию из центральной бизнес-системы, основанной на CSRP и используемой другими подразделениями организации. Рассмотрим следующий пример: продавец встречается с новым покупателем на его рабочем месте, и вместе они обсуждают текущие и будущие требования к продукту. Они обсуждают варианты, цены и услуги, подбирают решение, соответствующие уникальным требованиям покупателя, решение, которое ни один другой конкурент не может предложить сейчас. Используя приложение CSRP продавец способен записать специфические требования к продукту, зафиксировать цену и автоматически послать эту информацию в штаб-квартиру организации, где информация о требованиях к продукту динамически превращается в детальные инструкции по производству и планированию. Создается список материалов и комплектующих для производства, автоматически определяются производственные маршруты, материалы планируются и заказываются и, наконец, создается рабочий заказ. Критичная для покупателя информация динамически интегрируется в основную деятельность предприятия. После этого информация о критичных предпочтениях покупателя сохраняется в центральной базе данных о покупателях, которую могут использовать подразделения обслуживания покупателей, технического обслуживания, исследований, планирования производства Теперь рассмотрим следующее: тот же покупатель использует интернет-браузер для доступа к web-серверу производителя чтобы ввести заказ - стандартный или видоизмененный - в любое время дня или ночи. Покупатель может изменить предыдущие заказы, проверить состояние еще не выполненных заказов или запросить новые возможности. Т.к. такое взаимодействие интегрировано в основные бизнес-системы предприятия, деятельность по планированию, производству и/или обслуживанию покупателей может автоматически изменяться действиями покупателя. Открытые технологии делают оба эти сценария и методологию CSRP реальностью. Для CSRP требуется использование открытых технологий, которые могут интегрировать стратегические приложения подразделений в масштабируемые, защищенные приложения масштаба предприятия. Успешное внедрение CSRP возможно только при использовании открытых технологий. 69 Классификация ERP-систем Все корпоративные ИС можно классифицировать: 1) По числу одновременно работающих в системе пользователей 2) По отраслям промышленности 3) По архитектуре 4) По типу производства 5) По СУБД 6) По производителю 1) По числу одновременно работающих в системе пользователей: -Крупные (R/3, Oracle Applications) Такие системы дают широту охвата, включая управление производством, управление сложными финансовыми потоками, корпоративную консолидацию, глобальное Планирование отгрузок и закупок и бюджетирование и пр. Сходные функции присутствуют и во многих финансово-управленческих (за исключением производства) и средних интегрированных системах, однако, с более низкой степенью проработки. Сроки внедрения крупных интегрированных систем обычно занимают более года, а стоимость проекта – более 500 тысяч долларов США -Средние (Microsoft Axapta, Baan, Scala, Галактика) Средние интегрированные системы предназначены для управления производственным предприятием и интегрированного планирования производственного процесса. Цепочка оперативного планирования “сбыт – производство – закупки” является ядром таких систем (на основе процедур MRP-II). Подразделения инфраструктуры предприятия (финансы, бухгалтерия, маркетинг и пр.) строят свою деятельность, опираясь на данные этой цепочки. Такие системы значительно более сложны в установке (цикл внедрения может занимать от 6-9 месяцев до полутора лет и более).Стоимость внедрения средних интегрированных систем может достигать 500 и более тысяч долларов США. [9] -Малые (1С:Предприятие, Microsoft Navision) Такие системы предназначены для ведения учета по одному или нескольким направлениям (бухгалтерия, сбыт, склады, учет кадров и т.д.). Системами этой группы может воспользоваться практически любое предприятие, которому необходимо управление финансовыми потоками и автоматизация учетных функций. Цикл внедрения таких систем невелик, иногда можно воспользоваться “коробочным” вариантом, купив программу и самому установив ее на персональном компьютере. Стоимость локальных систем, в основном, колеблется в диапазоне 5-50 тысяч долларов США. Microsoft Navision относится к малым системам, Microsoft Axapta- к средним. 2) По отраслям промышленности: -машиностроение (Парус) -телекоммуникации (БОСС) -строительство (Галактика) -нефтегазовая (SAP/R3) 70 - торговля (1С:Бухгалтерия) -добывающая (Microsoft Navision) -здравоохрание (Oracle) - пищевая (Ростерминал) -легкая промышленность (1С:Предприятие ) Axaptу используют в таких отраслях, как машиностроение, строительная , добывающая отрасли , Microsoft Navision используется в основном в торговых организациях. 3) По архитектуре: - Двухуровневые (Axapta, Navision) Двухуровневая конфигурация системы (Рис.1.7) подразумевает выполнение всей логики приложения на рабочей станции пользователя системы. В случае сетевой многопользовательской работы все пользователи используют общую библиотеку приложения, для этого файлы приложения помещаются на общий файл-сервер (Application file server). Рис 1.7. Классическая двухуровневая конфигурация. - Трехуровневые (Microsoft Axapta, Maconomy) Использование Windows Terminal Server реализует конфигурацию с центральным сервером, обеспечивающим выполнение приложения и терминальными клиентами, контролирующими выполнение логики приложения в своих сессиях на терминальном сервере. (См. Рис. 1.8) Терминальный сервер Windows Terminal Server обеспечивает выполнение приложения на центральной серверной машине. Терминальным клиентам 71 предоставляется возможность контролировать работу приложения (подобно удаленному контролю) в рамках своей сессии через получаемые от терминального сервера экранные дисплеи работающего на сервере приложения [9] Рис 1.8. Конфигурацию с центральным сервером - Многоуровневые (R/3) Идея многоуровневых клиент - серверных архитектур заключается в реализации двух основных принципов: «тонкий клиент» — минимизация функциональности клиентских компонентов, оставляющая за клиентом только функции пользовательского интерфейса; максимальное упрощение и унификация клиентского программного обеспечения; освобождение сервера БД от несвойственных функций по реализации бизнесправил и логики конкретного приложения. На практике эти принципы реализуются введением в клиент-серверную систему дополнительного звена — серверов приложений. Термин «многоуровневые архитектуры» не предполагает какого-либо определенного принципа построения системы. Данное понятие применяется для характеристики любых архитектур, расширяющих схему клиент- серверного взаимодействия путем введения дополнительных промежуточных компонентов. С технологической точки зрения, используемые в настоящее время многоуровневые схемы можно разбить на три класса: 1. технологии с терминальным доступом; 72 2. Web-технологии; 3. технологии с разделением функций клиента («расщепленный клиентсервер»). По архитектуре Microsoft Axapta может иметь двухуровневую или трехуровневую конфигурацию, Microsoft Navision- двухуровневую. 4) По типу производства: -Дискретное (Microsoft Navision, Axapta) Это производство, осуществляемое путем сборки из отдельных частей. Пример: металлургия, химия, машиностроение. -Непрерывное (Галактика) - совокупность непрерывных технологических процессов, организованных в виде производственной линии, участка, цеха или предприятия в целом; диктуется характером технологии. Пример: нефте- и газодобыча. - Серийное (Паруc, Axapta) – характеризуется одновременным изготовлением на предприятии сравнительно широкой номенклатуры однородной продукции, выпуск которой повторяется в течение продолжительного времени. Пример: электроника, машиностроение. - Единичное (1С:Предприятие) - тип производства, характеризующийся единичным (штучным) изготовлением продукции разнообразной и непостоянной номенклатуры. Пример: авиация, тяжелое машиностроение. - Поточное (BAAN, Axapta)- метод организации производства, характеризующийся расчленением производственного процесса на отдельные, относительно короткие операции, выполняемые на специально оборудованных, последовательно расположенных рабочих местах - поточных линиях. Пример: машиностроение Microsoft Axapta поддерживает дискретное, серийное, поточное производство, Microsoft Navision - дискретное производство. .5) По СУБД: Классификация СУБД в зависимости от объема поддерживаемых БД и количества пользователей. - Высший уровень. Эти продукты поддерживают крупные БД (сотни и тысячи Гбайт и более), тысячи пользователей. В крупных корпорациях. Представители: ORACLE7, ADABAS 5.3.2, SQL SERVER11. - Средний уровень. Эти продукты поддерживают БД до нескольких сот Гбайт, сотни пользователей. В небольших корпорациях и подразделениях крупных фирм. Представители: InterBase 3.3, Informix-OnLine7.0, Microsoft SQL Server6.0. - Нижний уровень. Эти продукты поддерживают БД до 1 Гбайт, менее 100 пользователей. В небольших подразделениях. Представители: NetWare SQL 3.0, Gupta SQL-Base Server. Для Microsoft Axapta и Microsoft Navision обычно используют такие БД, как MS SQL Server и Oracle. 6) По производителю: 73 - Российские корпоративные информационные системы - Западные корпоративные информационные системы На российском рынке ERP-систем присутствует множество поставщиков: как иностранных, так и отечественных. По оценкам экспертов, львиную долю отечественного рынка (свыше 48%) занимает немецкий SAP AG, следом за ним идут продукты Microsoft Business Solution с долей около 13%, а замыкает тройку лидеров компания Oracle, занимающая чуть больше 11% российского рынка ERP-систем (См. Рис. 1.9). Рис.1.9. Доли ведущих поставщиков ERP-систем в России. Основные отличия между зарубежными и российскими системами заключаются в следующем: - Зарубежные системы ориентированы на хорошо структурированную иерархическую систему процессов, выполняемых на предприятии; - Зарубежные системы, как правило, опираются на наборы стандартов, которым должны удовлетворять процессы, например стандарт ISO 9000; - Зарубежные системы в настоящее время поддерживают полный набор управляющих функций (анализ, Планирование отгрузок и закупок, учет, контроль и регулирование); - Зарубежные системы включают приложения, использующие методы, позволяющие оптимизировать решения частных управленческих задач, например, выбор оптимального маршрута при управлении транспортом; - Российские системы, как правило, направлены на решение только задач учета и генерации бухгалтерской отчетности. [8] Microsoft Axapta и Microsoft Navision являются зарубежными системами. 74 ЛЕКЦИЯ №9 ТЕМА: Обзор ERP-систем «крупного» класса. Обзор рынка систем. Основной функционал систем, на примере системы SAP R3 Описание интегрированного пакета R3 Система R/3 является интегрированной системой, которая поддерживает все бизнес-процессы, протекающие на предприятии и объединяет их в режиме реального времени в компьютерную систему, которая может быть использована в целях планирования, регулирования, контроля хозяйственной деятельности предприятия. Отдельные модули R/3 отражают при этом экономические явления в форме стандартизованных процессов, представленных в информационных моделях и объединенных в систему (рис.2). SD FI Сбыт MM Управление материальными потоками PP Планирование производства QM Контроль качества PM Финансы CO Контроллинг AM Основные средства R/3 PS Клиент/Сервер Управление проектами ABAP/4 Управление WF ТО ремонт оборуд. HR Управление персоналом IS потоками заданий Отраслевое решение Рис. 2. Модули системы R3 Благодаря открытой архитектуре блоки системы R/3 могут быть использованы на базе различных компьютерных и программных систем, баз данных и сетей. Применение R/3 возможно на платформах следующих операционных систем: IBM AIX, IBM AS/400, HP-UX, BULL AIX, Didital UNIX, SUN Solaris, SNI SINIX, Windows NT, Data General, Sequent, AT & T. Для интерфейсов и платформ баз данных : Oracle, Oracle Parallel Server, Informix, ADABAS/D, DB2 для AIX, DB2 для AS/400, Microsoft SQL Server. Платформы внешних интерфейсов: Windows 3.1, Windows 95, Windows NT, OS/2 PM, UNIX/Motif, Apple Macintosh. Компьютерный парк для системы R/3 включает: один центральный компьютер - сервер базы данных; связанные с сервером по сети компьютеры отделов, на которых реализуется логика обработки диалогов с пользователем; персональные компьютеры на рабочих местах для ввода-вывода данных для пользователей системы. 75 Ядро системы R/3 образуют 3 связанные между собой программные базовые подсистемы «УЧЕТ», «ЛОГИСТИКА», «УПРАВЛЕНИЕ ПЕРСОНАЛОМ», а также 3 локальные подсистемы «ОФИС И КОММУНИКАЦИИ», «УПРАВЛЕНИЕ ПРОЕКТАМИ», «ОТРАСЛЕВЫЕ РЕШЕНИЯ». Рис. 3. Функциональные блоки системы R3 Базовая система R/3 образует структурные рамки для отдельных систем и программ, обеспечивает оптимальное взаимодействие программ в системной среде и определяет рамки для расширения системы. Наряду с интеграцией программ, единой пользовательской средой, единой системой управления данными и информацией, единой концепцией управления различными процессами, базовая система R/3 содержит инструменты для управления всеми подсистемами и обеспечивает распределение ресурсов и отдельных компонентов системы. Кроме того, система реализует интерфейс для децентрализованных компонентов системы и сторонних систем. 5.1 Функциональный блок «Учет и отчетность» Данный модуль охватывает программные решения для финансового и производственного учета, учета основных средств и контроллинга. Интерфейс для Логистики и Управления персоналом создает возможность единого представления внутрифирменных процессов. 76 Спектр функций модуля «Финансы» включает программные решения для таких сфер бухгалтерского учета как главная бухгалтерия, учет дебиторской и кредиторской задолженности, а также для сфер финансового контроллинга, финансовых инвестиций, консолидации и контроля финансовых средств. Центральный принцип финансового учета - упорядоченность бухгалтерии: базой всех проводок являются данные первичной учетной документации; центральный элемент интеграции - совместно используемый план счетов, обеспечивающий автоматические проводки всех операций в соответствии с единой классификацией счетов. Функциональная область «Главная бухгалтерия» поддерживает все функции внешнего учета. Обеспечивается возможность свободного выбора структуры счетов, ведения нескольких главных книг, параллельного ведения главной книги и счетов управленческого учета, формирования различных версий баланса, а также специфической обработку экономической информации для условий конкретного предприятия. Балансы, как и счет прибылей и убытков, базируются на актуальной информации и могут быть сформированы в режиме реального времени. Модули «Учет дебиторов и кредиторов» наряду с текущим автоматизированным охватом в режиме on-line дебиторской и кредиторской задолженностей реализуют также и классические задачи управления дебиторами и кредиторами (анализ счетов, контроль за поступлением платежей и выставлением претензий, осуществление выплат и выставление векселей, и т.п.). При помощи внутренних информационных потоков осуществляется регулярное информационное обеспечение служб снабжения и сбыта. Интерфейсы с расчетами прибыли и рыночных результатов, а также с управлением наличностью охватывают результативную и финансовую сторону каждого процесса. Ядром функциональной области «Управление наличностью» является автоматическая организация платежных потоков с учетом всех распределительных процессов. Кроме того, при помощи данного функционального блока осуществляются актуальное представление движения счетов, электронных платежей, расчеты финансовых потоков и поддержка прямого финансового планирования. Анализ и оптимизация структуры и управление капиталом (финансирование и дефинансирование) поддерживаются функциональным блоком «Управление ценными бумагами». Связанный с блоком управления активами и другими частями финансов функциональный блок «Консолидация» осуществляет объединение отдельных отчетов в общий отчет концерна. Наряду с отчетами, регламентированными законодательством, могут разрабатываться консолидированные планы и внутригодовые отчеты. Полностью интегрированный в блок учета модуль «Учет финансовых потоков» поддерживает планирование и регулирование движения, также распределение всех финансовых средств предприятия. Также поддерживается своевременное и детальное бюджетирование, составление отчетности об использовании средств и контроль исполнения бюджетов, регулирование использования средств для инвестиций, производства и поддержки текущей деятельности предприятия. Спектр функций «Управление основными средствами» дает возможность сопровождать различные позиции основных средств на всем протяжении их жизненного цикла - от этапа планирования инвестиций до утилизации или продажи основных средств, - и охватывает ключевые элементы инвестиционного контроллинга, учета активов, а также техническое управление основными средствами. Благодаря информационной связи с модулями Учета и Логистики открывается возможность сквозного управления активами. Модуль «Инвестиционный контроллинг» поддерживает планирование, регулирование, контроль инвестиций и дезинвестиций. В распоряжении пользователей имеются также различные альтернативные методы инвестиционных расчетов и имитационных моделей. Модуль «Учет основных средств» обеспечивает учет и обработку 77 информации, связанной с амортизацией, выбытием и поступлением активов, а также с переносом информации с одного счета на другой. Пользователь имеет свободу выбора метода амортизации, способа оценки активов, ставки процента и условий страхования. Модуль «Техническое управление основными средствами» поддерживает осуществление договоров по обслуживанию и ремонту оборудования, а также по планированию и контролю затрат на техническое обслуживание оборудования. Блок «Контроллинг» является базой, обеспечивающей планирование, ориентированное на результат, регулирование и контроль всех процессов на предприятии. Он включает такие ключевые элементы как учет по местам возникновения затрат, учет объемов производства, краткосрочное планирование и контроль затрат, учет затрат по договорам и проектам, учет затрат по их носителям (с различными видами калькуляции - по штукам, группам, времени), расчет результатов по сегментам рынка, группам продуктов и услуг, расчеты по центрам возникновения прибыли и по процессам. Благодаря данным элементам Контроллинг составляет основу интегрированной УИС. Реализуемые в рамках R/3 сквозные расчеты обеспечивают предприятию возможность монетарного представления последствий изменения программы производства, потенциала и реализации альтернативных мероприятий. В результате формируется интегрированная информационная база целенаправленного управленческого процесса, охватывающая все аспекты деятельности предприятия от снабжения до производства и сбыта. Модуль «Учет по местам возникновения затрат» обеспечивает планирование и контроль по видам затрат в местах их возникновения. Разные методы учета затрат (например, учет на базе полных плановых затрат, учет затрат по процессам) предполагают использование различных способов калькуляции. Обеспечивается также согласование с бухгалтерским учетом. Модуль «Учет затрат по договорам и проектам» в рамках интегрированного контроллинга обеспечивает детальный учет в разрезе договоров и проектов. Путем сравнения плановых и фактических показателей обеспечивается возможность текущего контроля. Модуль «Учет затрат по продуктам» поддерживает калькуляции по продуктам и позволяет планировать затраты на материалы с/без спецификацией и техкартой, и на другие объекты учета затрат, а также позволяет контролировать структуру затрат по их видам и рабочим процессам, прогнозировать затраты по периодам и объектам. Калькуляция затрат на продукт сочетает функции калькуляции затрат на изделие и калькуляции узлов изделий. Калькуляция затрат на изделие входит в оба модуля: PP (Планирование и регулирование производства) и СО (Контроллинг). Однако калькуляцию затрат на изделие/узел можно проводить и без использования спецификаций и технологических карт, создаваемых в модуле РР, достаточно данных материала, получаемых из модуля ММ. Модуль «Учет по видам затрат» обеспечивает возможность прогнозировать и анализировать результаты за период по отдельным видам продукции и группам видов продукции. Под видами затрат понимаются соответствующие расходные счета отчета о прибылях и убытках в модуле FI. Модуль «Учет результата по сегментам рынка» позволяет планировать прибыль и объемы сбыта по видам продукции, договорам и сегментам рынка. Помимо прочего, этот модуль обеспечивает анализ актуальных рынков и позиции предприятия на этих рынках. Модуль «Учет по местам возникновения прибыли» позволяет определять результаты за период по отдельным подразделениям предприятия. На местах возникновения прибыли показываются результаты, которые выявляются на основе метода учета затрат по обороту и/или на основе метода учета общих затрат. Модуль «Контроллинг предприятия в целом» - часть банка управленческих моделей EIS (Executive Information System), этот модуль позволяет собирать информацию 78 о подразделениях предприятия и представлять ее при необходимой степени обобщения в форме управленческой информации. Свободное определение структуры отчетов позволяет проводить индивидуализированный анализ и исследования. Управленческая информация (т.е. информация для целей планирования, регулирования и контроля) формируется автоматически в рамках модели открытого информационного склада (рис.3). EIS управленческая информационная система LIS информационная система логистики CIS контроллинговая информационная система FIS информационная система финансов PIS информационная система персонала Информация для исполнения Деятельность по исполнению Децентрализованная оперативная система Внешняя система Рис. 3 Модель открытого информационного склада Эта модель передает управленческую информацию, подготовленную модулями системы R/3, менеджерам на различных уровнях управления. Базой для подготовки такой информации являются информационные системы отдельных модулей (логистика, контроллинг, финансы, персонал). EIS позволяет объединять информацию, получаемую из подразделений предприятия, а также из внешних источников (например, рыночные данные) и тем самым дает возможность высшему руководству быть в курсе всех экономических явлений и процессов на предприятии даже при децентрализованной системе управления. 5.2 Функциональный блок «Логистика» 5.2.1 Подсистема «Управление материальными потоками» Модуль «Структура складского хозяйства» позволяет управлять областями складирования и складскими местами на складе, обрабатывать все существенные проводки и операции, такие как поступление материала, отпуск материала и общее перемещение запасов, отслеживать перемещение запасов, производить инвентаризацию на уровне складских мест, гарантировать соответствие между запасом, проведенным через систему управления запасами, и запасом на складе, осуществлять интеграцию с системами управления материалами, управления продуктами, управления качеством и сбытом. Модуль «Контроль счетов и оценка запасов» обеспечивает связь между компонентом Управления материальными потоками и компонентами Финансовой бухгалтерией, контроллинга, и бухгалтерского учета основных средств. «Контроль счетов» служит следующим целям: выполняет процесс заготовки материала, который начинается с заявки на материалы, продолжается в соответствие с операциями закупки и поступления материала и заканчивается поступлением счета-фактуры; позволяет обрабатывать счета, не возникающие при заготовке материала (например, услуги, расходы, курсовые стоимости, и т.д.); позволяет обрабатывать кредитовые авизо, ликвидацию счетов или скидок. 79 «Контроль счетов» не обрабатывает платежи и не проводит анализ счетов. Информация необходимая для этих процессов обрабатывается другими модулями системы. В задачи «Контроля счетов» также входит: ввод полученных счетов и кредитовых авизо; проверка точности счетов в отношении содержания, цен и арифметики; выполнение проводки бухгалтерского счета соответствующего счету-фактуре; модификация определенных данных в системе R/3, таких как, открытые позиции и цены материала; проверка счетов, блокированных из-за расхождения с заказом на поставку. Модуль «Оценка запасов» содержит следующие рабочие области: операции закупки, управление запасами, контроль счетов. Модуль оценки запасов материалов является связующим между модулями управления материальными потоками и финансовой бухгалтерии, так как он обновляет основные счета финансовой бухгалтерии. Модуль «Управление запасами материалов и инвентаризация» позволяет: управлять запасами в стоимостном и количественном отношениях, осуществлять планирование, ввод и проверку любых движений запасов материалов, проводить инвентаризацию по следующим методам: инвентаризация на определённую дату, выборочная инвентаризация, периодическая инвентаризация. Модуль «Планирование Потребности в Материалах» имеет главной целью контроль запасов и, в частности, автоматическое составление проекта заказа для закупок и производства (плановые заказы, заявки или разверстки графиков поставок). Это достигается использованием разнообразных методов планирования потребности в материалах. Для достижения бесперебойности материальных потоков необходимо постоянное взаимодействие между всеми участниками процесса. Необходимый канал информации обеспечивается тесной интеграцией системы управления запасами в систему R/3 и связью с другими модулями R/3, в том числе: финансами (FI) - система обеспечивает автоматическое обновление не только наличного количества материала по каждому факту поступления или отпуска материала, но и обновление записей соответствующих счетов финансовой бухгалтерии; контроллингом (CO) - интерфейс к системе учета затрат вступает в действие при расходе материала (например, при выдаче материалов для места возникновения затрат); бухгалтерским учётом основных средств (AM) - если материалы, затраченные на основные средства, заказаны извне или выписаны со складов, соответствующие движения товаров контируются на счета запаса основных средств. При этом с помощью модуля бухгалтерского учёта основных средств создается новая отдельная позиция в записях об основных средствах. 5.2.2 Модуль «Планирование и регулирование производства» (PP) Модуль «Спецификации» является основой для различных видов деятельности по планированию производства на основе данных, содержащихся в спецификациях. Отдел проектирования (CAD) может построить свою работу на основе спецификаций. В системе R/3 существует возможность создания спецификации средствами внешней CAD программы, используя интерфейс CAD. Спецификации используются в планировании потребления материалов (ППМ), для планирования операций и управления производством при подготовке производственного процесса, в управлении заказами на производство для планирования предоставления материала (ППМ). Модуль «Рабочие места и технологические карты» используются в операциях следующих объектов: единичной технологической карты, календарно-плановых нормативов, стандартной технологической карты, технологической карты контроля, технологической карты ТОРО. Наиболее важными элементами техкарты являются 80 операции, компоненты материала, вспомогательные производственные средства, контрольные признаки. В системе R/3 техкарты используются в производственных заказах, при календарном планировании, при планировании производственных мощностей, в калькуляциях. Модуль «Производственные заказы» содержит сведения о том, какой материал необходимо произвести, где он должен быть произведен, какие работы для этого необходимо выполнить и к какому сроку, какие ресурсы необходимы в производственном процессе, а также как следует рассчитывать затраты по заказу. Как только планируемый заказ или внутреннее требование появляется с предыдущего уровня планирования (ППМ), управление производством добавляет специфичные для заказа данные (такие как сроки и объемы) к уже существующей информации. 5.2.3 Модуль «Техническое Обслуживание и Ремонт Оборудования» (ТОРО) Включает в себя следующие основные модули: «Структурирование основных средств», «Спецификации и технологические карты ТОРО», «Планирование ТОРО», «Расчет затрат на ТОРО». «Структурирование основных средств» обеспечивает логическое структурирование технических объектов на предприятии и предоставляет следующие преимущества: сокращение времени управления объектами, упрощение обработки техобслуживания, существенное сокращение времени ввода данных в обработку техобслуживания, более точная, тщательная и быстрая оценка данных техобслуживания. «Спецификации и технологические карты ТОРО».В техкартах ТОРО описывается последовательность отдельных мероприятий ТОРО, которые должны регулярно выполняться на техническом объектах, таких как контроль технического состояния, техническое обслуживание, ремонт. «Планирование ТОРО» используется для того, чтобы оценить, где на производственном предприятии нужны мероприятия по проведению техобслуживания. При этом необходимо учесть обеспечение качества (качество продукции сильно зависит от условий производства на предприятии), сведения за прошлые периоды (что показывают записи за прошлые периоды для основных средств, содержат ли они историю простоев, которые можно было бы предотвратить с помощью обычного технического обслуживания), причина простоя (что вызывает простой основных средств, был ли сбой вызван самим оборудованием). «Расчет затрат на ТОРО» является важным аспектом произведенных действий по техобслуживанию и ремонту оборудования. Для проведения эффективного техобслуживания и ремонта, а также для планирования проведения будущих задач ТОРО с наименьшими затратами вводится структура затрат. В этой структуре собирается, обобщается и хранится информация о затратах на ТОРО. Вывод затрат особенно важен для ТОРО: он не подчиняется обычным способам учета затрат и должен настраиваться особым образом. 5.2.4 Модуль «Сбыт» (SD). Модуль «Продажи» включает следующие функциональные области: торговые документы и работа с ними, запросы и предложения, заказы клиентов, соглашения о поставках и контракты, рекламации клиентов, неподтвержденные заказы, информация о продажах и анализ продаж. Модуль «Отгрузка» включает контроль заказов с наступившим сроком поставки, создание и обработку поставок, контроль готовности материала, комплектование (поддерживается системой управления складами), упаковка поставок, печать и 81 отправление выходных документов отгрузки, проводки отпуска материалов, контроль рабочего списка в отгрузке. Модуль «Фактурирование» выполняет следующие функции: Создание: счетов поставок и услуг, кредитовых и дебетовых авизо по запросам, счетов-проформ. Расторжение транзакций фактурирования. Выдача бонусов. Перенос данных бухучета в финансовую бухгалтерию (модуль FI). В системе R/3 эти функции осуществляются с помощью различных документов фактуры. Документы фактуры позволяют решать как ежедневные организационноэкономические, так и специальные задачи. Подобно всем компонентам обработки заказов в системе R/3, фактурирование интегрировано в организационные структуры. Наличие связи между фактурированием и финансами увеличивает значимость организационных структур бухгалтерского учета, а также сбытовых организаций. Модуль «Расчет цен» используется для вычисления цен (для дебиторов и кредиторов) и затрат (для внутренних нужд, например, для учета затрат). В соответствии с конкретными условиями автоматически вычисляются цена брутто, скидки и надбавки. Модуль «Кредитный менеджмент». На основании самых свежих данных модулей финансов (FI) и сбыта (SD) разрабатывается эффективная кредитная политика, способствующая снижению кредитного риска, в случае превышения кредита производится блокирование соответствующих документов. Кредитный менеджмент предоставляет следующие возможности: Автоматическая проверка кредитов, основанная на различных критериях в соответствии с индивидуальными нуждами организации. Существует возможность задания критических точек процесса сбыта для проведения в них автоматической проверки кредита. Автоматическое оповещение сотрудников отдела кредитного менеджмента о возникающих критических кредитных ситуациях с помощью электронных систем связи. Быстрая и точная проверка кредитной ситуации дебитора лицами, ответственными за предоставление кредита, что дает возможность быстро принять решение о предоставлении кредита в соответствии с кредитной политикой организации и реальным положением дел. Модуль «Внешняя торговля». Вся логическая цепочка, от импорта сырья, готовых изделий и полуфабрикатов, до продажи товаров и передачи данных модулям планирования потребности в материалах (ППМ) и финансовой бухгалтерии, подвергается заметному влиянию операций внешней торговли. Система R/3 позволяет выполнять основные операции обработки внешней торговли. Для этого используются следующие функции: ведение данных, относящихся к внешней торговле, в следующих основных записях: основной записи дебитора, основной записи кредитора, основной записи материала, информационной записи закупки; копирование данных внешней торговли в документы закупки и документы сбыта для дальнейшей обработки; интерфейс для сбора данных по экспорту. экспортный контроль. 5.3 Обзор программного модуля «Персонал» (HR). 82 Модуль поддерживает следующие функции: управление основными данными по персоналу, расчет нормативов времени, оценка и статистика затрат на персонал, расчеты заработной платы и окладов, планирование персонала, отбор кандидатов, расчет командировочных расходов. 5.4 Обзор локальных подсистем. 5.4.1 Обзор программного модуля «Офис и коммуникации». Основной функциональный компонент офиса - SAPoffice - это система папок и электронной почты. Почтовая система позволяет отправлять сообщения корреспондентам как внутри организации (другим пользователям R/3 в той же системе), так и вне ее (пользователям R/3 в другой системе, или не пользователям SAP). Для внешней отправки документов используются электронная почта, X.400 или Internet-mail. Пользователям R/3 в другой системе документы посылаются с помощью SAPcomm. Приложения R/3 используют также - со ссылкой на функцию управления выходными документами - такие компоненты связи, как SAPoffice или SAPcomm для прямой передачи документов (заказов на поставку, счетов, напоминаний и т. д.) 5.4.2 Модуль «Проектная система» (PS). Модуль представляет собой комплексный инструмент планирования, регулирования, реализации и контроля проектов. Цель - оптимизация хозяйственных процессов на предприятии, а также сокращение объемов рутинной деятельности. При этом поддерживаются различные проекты, например проекты НИОКР, отдельные заказы на единичное производство, инвестиционные и маркетинговые проекты. Модуль обеспечивает решение всех задач в сфере управления проектами независимо от отраслевых особенностей. Интеграция проектной системы в общую структуру R/3 обеспечивает учет требований различных функциональных подразделений, а также поддержку на всех фазах проекта. 5.4.3 Специальный модуль «Отраслевые решения» (IS). Модуль облегчает применение системы R/3 в банках, страховых компаниях, издательствах, больницах, на электростанциях, нефтеперерабатывающих предприятиях и т.п. Типичные производственные и коммерческие процессы определяются в рамках специальной ссылочной (референтной) модели. Отраслевые и ориентированные на потребности клиента задачи решаются без сложных модификаций системы путем управления электронными таблицами. Так как рассмотренные выше стандартные модули, несмотря на отвечающую требованиям пользователя параметризацию, все-таки не позволяют покрыть весь спектр пожеланий клиентов, система может быть дополнена внешним программным обеспечением ли самостоятельно разработанными программами, написанными на предлагаемом фирмой SAP AG языке программирования четвертого поколения АВАР/4 (Advanced Business Application Programming). 83 ЛЕКЦИЯ №10 ТЕМА: Обзор ERP-систем «среднего» класса. Обзор рынка систем. Основной функционал систем, на примере системы Microsoft DynamicsAx. Обзор системы Корпоративная Информационная Система Microsoft Dynamics AX (Microsoft Business Solutions – Axapta) - это современная интегрированная система класса ERP II, созданная для средних и крупных многопрофильных предприятий различных секторов экономики. Система удовлетворяет всем высоким требованиям методологии и идеологии ERP II, при этом она соответствует требованиям российского делопроизводства, что особенно важно для отечественныхпредприятий. Система Microsoft Dynamics AX (Microsoft Business Solutions – Axapta) не только полностью переведена на русский язык, но и настроена на российские стандарты. Так, 24 сентября 2003 года система была сертифицирована Институтом профессиональных бухгалтеров России и рекомендована департаментом методологии бухгалтерского учета и отчетности Министерства финансов РФ. Система Microsoft Dynamics AX (Microsoft Business Solutions-Axapta) была также удостоена сертификата Института Профессиональных Бухгалтеров России, специалисты которого подтвердили, что методология продукта соответствует правилам бухгалтерского учета Российской Федерации. Microsoft Dynamics AX (Microsoft Business Solutions – Axapta) решает важную задачу - объединяет деятельность всех подразделений предприятия на базе единой интегрированной информационной и методологической системы. Мощная технологическая платформа системы Axapta (открытый исходный код модулей, интегрированная среда разработки Morph X, собственный объектно-ориентированный язык программирования X++ и т.д.) поможет предприятию оптимизировать все свои внутренние и внешние бизнес-процессы и добиться новых конкурентных преимуществ, повысив эффективность своей экономической деятельности. 84 Система обладает очень важной для российских предприятий особенностью – она изначально ориентирована на адаптацию к существующим на предприятии экономическим условиям. Это означает, что, благодаря встроенным в систему средствам разработки и инструментов для интеграции с другими приложениями, центром внедрения становится не столько функциональность системы, сколько бизнес-процессы заказчика.\ Таким образом, при правильном внедрении и грамотной постановке экономических задач возможно создание уникального продукта, идеально подходящего для данного конкретного предприятия и соответствующего при этом мировым и российским экономическим стандартам. Преимущества Axapta 1. Новые функциональные возможности – качественно новая информация для принятия решений. o Определение прибыльности отдельных подразделений o Получение новых аналитических данных по продажам и затратам. o Встроенные функции кредитного контроля. 2. Ускорение и повышение эффективности учета. o Сокращение сроков по закрытию отчетности с нескольких недель до нескольких дней. o Упрощение процесса получения управленческой и международной отчетности. o Прозрачность системы для аудита. 85 Однократный ввод данных, что снимет вероятность многих потенциальных ошибок. 3. Оптимизация бизнес-процессов. o Улучшение обмена информации между различными службами и подразделениями компании, что существенно сократит издержки производства. o Возможность анализа и планирования на каждом этапе любой деятельности предприятия. Благодаря системе Axapta пользователь получает консолидированную информацию о любом самом сложном бизнес-процессе компании. o Система Axapta оказывает не только прямой экономический эффект на деятельность фирмы. Некоторые результаты внедрения нельзя оценить в денежном выражении, но недооценивать их роль в развитии бизнеса нельзя. Это, может быть, и: 1. Завоевание большего сегмента рынка за счет улучшения качества обслуживания клиентов и сокращение сроков бизнес-процессов (обслуживание клиентов, выход новой продукции, предоставление новых услуг). 2. Обход критических ситуаций на рынке или, наоборот, использование самых выгодных возможностей благодаря получению своевременной и полной информации о деятельности компании и благодаря самым современным инструментам прогнозирования и планирования. 3. Снижение издержек, связанных с ошибками персонала и выполнением ненужных действий. Система делает все один раз, четко, верно и надежно. Масштабируемость системы позволяет: Внедрять новые модули системы Axapta в процессе эксплуатации, при чем все они совместимы друг с другом и с модулями, которые уже внедрены (функциональная масштабируемость). Сохранять высокую производительность и выполнять все функции системы при изменении масштаба деятельности. Если при внедрении была предусмотрена автоматизация 50 рабочих мест, а через год потребовалось их увеличить до 200, работа системы не нарушится, и все новые рабочие места будут обладать теми же возможностями, что и исходные (масштабируемость по мощности). Финансовый контур Финансовый контур системы Microsoft Dynamics AX (MBS Axapta) позволяет предприятию автоматизировать все свои финансовые бизнес-процессы, повысить эффективность работы по ведению бухгалтерского, налогового и управленческого учета на предприятии в соответствии с российскими стандартами (РСБУ, МСФО или GAAP) и принятыми нормами отчетности. Основные модули финансового контура: Главная книга Денежные средства Расчеты с поставщиками Расчеты с клиентами 86 Установка финансового блока системы Microsoft Dynamics AX (MBS Axapta) дает предприятию значительные преимущества, облегчающие деятельность всех подразделений компании: 1. возможность проведения независимого учета сразу в нескольких компаниях, что соответствует требованиям организаций, имеющих несколько офисов, филиалов или дочерних компаний. Консолидация данных может проводиться как в интерактивном режиме, так и путем экспорта/импорта данных. 2. структурированный план счетов. В системе созданы все условия для упрощения и наглядности работы со счетами. По каждому счету устанавливаются валюты, в которых проводятся операции, порядок разнесения операций по кодам аналитики, типы разноски пользователей, имеющих право на выполнение расчетов по данному счету. При этом в финансовых модулях системы, как и в других ее составляющих, реализован принцип сквозного просмотра, позволяющий отслеживать всю документацию и все проводки по данной конкретной операции, что значительно ускоряет и облегчает работу всех отделов предприятия. При учете деятельности нескольких предприятий можно создавать операции сразу в нескольких компаниях, при этом осуществляется автоматическое сохранение данных. 3. интегрированная работа всех составляющих системы. Все модули являются частью одной системы, тесно взаимодействуют друг с другом. Это означает, что на предприятии будет осуществляться оперативное обновление всех данных, которое приводит к получению быстрой и точной финансовой отчетности. При этом, выполняется условие прозрачности информации, в любой момент можно отследить происхождение каждой проводки и посмотреть документ, на основании которого были выполнены обновления. 4. осуществление финансового планирования. В рамках системы возможно прогнозирование ликвидности и бюджетирование предприятия. Бюджеты составляются на любой период и в любой валюте. Возможно автоматическое создание бюджетов. При этом, можно задать связь между созданными бюджетными позициями и, указав правила этой связи, сформировать бюджетную модель для решения вопроса планирования: «Что будет, если…». При получении финансовой отчетности возможно сравнение фактических показателей с бюджетными, на основании которого подсчитываются расхождения. Бюджетирование можно проводить на уровне счетов Главной Книги, отдельных клиентов или поставщиков, а также групп клиентов и поставщиков. 5. удобное формирование отчетности. В системе Microsoft Dynamics AX (MBS Axapta) имеются все основные финансовые и бухгалтерские отчеты: Главная Книга, Оборотно-сальдовая ведомость, Журнал ордер/ведомость и др. Кроме того, создан инструментарий для формирования других отчетностей: o стандартный генератор отчетов позволяет на базе исходного плана счетов создавать отчетность в корпоративных и международных стандартах (IAS, GAAP и т.д.). Данные отражаются в требуемой валюте. o российский генератор отчетов позволяет формировать отчеты с использованием шаблонов Microsoft Word и Microsoft Excel, что удобно с точки зрения быстрой модификации шаблонов документов, а также корректировки отчетов вручную по необходимости. 6. надежность и защищенность информации. Благодаря уникальному идентификатору, расширенным средствам настройки прав доступа, в системе обеспечивается высокий уровень безопасности данных. При этом все модули Microsoft Dynamics AX (MBS Axapta) имеют встроенные средства системного контроля, которые не позволяют удалять операции, произведенные в системе. 87 7. возможность многовалютного учета (конвертация валют, проводки по курсовой/суммовой разнице) с использованием различных языковых режимов. В рамках организованных в системе журналах операций можно указать валюту операции, коды аналитики для проводок, необходимость одобрения операции конкретным пользователем перед разноской по счетам Главной Книги. При этом обеспечивается ежедневное ведение курсов неограниченного числа валют, что позволяет формировать по единому массиву данных отчеты для налоговых органов, управленческие и корпоративные отчеты, решая, таким образом, задачу мультивалютного учета. Главная книга Модуль Главная Книга является центральным для большинства процессов в системе MBS Axapta. В нем настраиваются основные элементы бухгалтерского и управленческого учета и представлена вся финансовая деятельность предприятия. На счетах Главной Книги хранится информация об операциях, проведенных в различных модулях системы. В модуле Главная Книга возможно выполнение таких операций, как: задание основных финансовых элементов и справочников (планы счетов, картотеки валют, настройки налогового учета, порядок формирования и нумерации финансовых и бухгалтерских документов, счета учета расчетов между компаниями и т.д.); ежедневная регистрация хозяйственных операций (оплата от заказчиков, расчеты с подотчетными лицами, начисление налогов, операции по кассе и банку и т.д.); финансовое планирование; анализ ликвидности; переоценка валютных счетов; перекладка данных в системы учета в соответствии с международными стандартами; расчеты между компаниями и консолидация данных дочерних компаний; автоматическое распределение затрат; настройка и генерирование отчетности. Модуль Главная Книга обладает рядом преимуществ, среди которых: оперативное обновление. Автоматическое обновление данных в Главной Книге сокращает время, необходимое для обновления и выверки из различных данных вручную. Например, заказ, по которому выписана накладная, автоматически отражается на счетах Главной Книги и на счете клиента. Также возможно отследить происхождение каждой проводки, посмотреть документ, на основании которого была выполнена операция. наличие специального графического инструмента для анализа фактических и бюджетных данных в системе (гистограммы, круговые и объемные диаграммы и т.д.). При этом в бюджет Главной Книги возможна интеграция бюджетов, сформированных в рамках других модулей системы, например, бюджет продаж или бюджет по основным средствам. Денежные средства Модуль Денежные Средства позволяет пользователю провести комплексную автоматизацию кассовых и банковских операций при тесной интеграции с другими модулями финансового блока: 88 Главная книга. Взаимодействие осуществляется путем формирования проводки, как по Кассе, Банку, так и по счетам Главной Книги. Возможно формирование и разноска кассовых ордеров или банковских операций в общем журнале ГК. Расчеты с клиентами. Расчеты с поставщиками. Интеграция модулей происходит при учете наличных, безналичных расчетов с контрагентами, расчетов с использованием векселей и аккредитивов. При разноске операций с контрагентами проводки формируются по Клиенту/Поставщику, Кассе, Банку, Главной Книге. Модуль Денежные средства позволяет автоматизировать проведение операций получения/выдачи наличных средств, создание первичных документов, печати отчетов и т.д. в соответствии с требованиями российского бухгалтерского учета. В рамках данного модуля возможно выполнение следующих кассовых и банковских операций: Кассовые операции Банковские операции Ведение наличных расчетов Ведение расчетов по счетам в банках. Счета разного типа, открытые в одном банке, объединяются в группу банка. Учет поступления и расходования наличных денежных средств Формирование, подготовка и подтверждение платежного поручения. Учет кассовых операций в различных валютах Выверка с выпиской из банка и разнесение банковских журналов по счетам Главной Книги. Ведение кассовой книги предприятия (типовая форма КО-4) Формирование реестра простых векселей. Формирование типовых форм по учету наличных (КО-1, КО-2, КО-3) Контроль предельного размера расчетов между юридическими лицами Печать первичных документов и соответствующих отчетов (приходных и расходных кассовых орденов, авансовых отчетов). Расчеты с клиентами Модуль Расчеты с клиентами содержит всю необходимую информацию о клиентах компании, располагает инструментами для отслеживания и эффективного управления дебиторской задолженностью и предназначен для выполнения ряда таких операций, как: 1. 2. 3. 4. 5. 6. 7. 8. Выставление клиентам счетов-фактур и кредит-нот; Регистрация клиентских платежей; Регистрация и работа с клиентскими векселями; Сопоставление работ по клиентам; Ведение прейскурантов и условий для предоставления скидок; Печать документов на различных языках; Ведение и отслеживание дебиторских лимитов; Контроль сальдо; 89 9. Создание отчетов по расчетам с клиентами. Расчеты с поставщиками Модуль Расчеты с поставщиками предоставляет инструментарий для расчета предприятия с поставщиками, подрядчиками и прочими кредиторами. Модуль поддерживает различные условия поставки и оплаты, а также позволяет вести расчеты в разных валютах и работать в разных языковых режимах. В рамках данного модуля могут осуществляться такие операции, как: 1. 2. 3. 4. 5. 6. 7. 8. 9. Проведение частичных платежей; Автоматический расчет курсовых разниц; Переоценка валютных счетов расчетов с кредиторами; Регистрация неодобренного счета (накладной); Одобрение накладной (в соответствии с правилами учета предприятия); Сопоставление накладных и платежей; Регистрация счетов-фактур от поставщика; Обработка НДС и формирование книги покупок; Учет операций с подотчетными лицами – формирование авансовых отчетов, контроль выдачи наличных под отчет. Основные средства Модуль Основные средства тесно интегрирован с другими модулями системы, выполняет функцию автоматизации учета основных средств, нематериальных активов с момента их постановки на учет до выбытия и позволяет осуществлять следующие операции: 1. Начисление амортизации и отражение в учете других операций с каждым объектом амортизируемого имущества по неограниченному числу моделей учета – в соответствии, например, с требованиями российского бухгалтерского и налогового учетов, международного корпоративного и управленческого учета. 2. Формирование регламентированной российской отчетности (типовые формы №№ ОС-1, ОС-1а, ОС-2, ОС-3, ОС-4, ОС – 4а, ОС-6, ОС-14 и т.д.). 3. Сохранение подготовленных отчетов в форматах Microsoft Word и Excel, ведение архива подготовленных документов. 4. Настройка неограниченного количества различных схем амортизации, групп основных средств и профилей разноски операций в Главную книгу. 5. Начисление износа пропорционально количеству выпущенной продукции и пробегу автотранспортных средств; в соответствии со Справочником единых норм амортизационных отчислений; и возможность распределения начисленного износа по счетам производственных и непроизводственных затрат пропорционально применению объектов основных средств (зданий, сооружений). 6. Учет арендованных и сданных в аренду основных средств. 7. Изменение сроков службы основных средств при капитальном ремонте или переоценке стоимости. Сохранение истории таких операций с отражением в соответствующих отчетах. 8. Проведение инвентаризации основных средств по подразделениям. 9. Учет перемещений основных средств и нематериальных активов, как между подразделениями внутри компании, так и между компаниями. 10. Выполнение переоценки объектов амортизируемого имущества и начисленной амортизации, как по рыночной стоимости (вручную), так и по коэффициентам. 90 11. Учет основных средств и нематериальных активов в валюте для иностранных представительств с перерасчетом рублевого эквивалента стоимости и начисленной амортизации. 12. Налоговый учет амортизируемого имущества. 13. Планирование и бюджетирование. Все операции осуществляются одновременно с использованием неограниченного количества моделей учета в одной компании. Для каждой модели определяется валюта, профиль разноски, коды финансовых аналитик и т.д. Модуль Основные средства позволяет проводить любые необходимые операции по ведению налогового учета (операции по расчету, учету амортизации и амортизируемых средств, формирование налоговых проводок и т.д.). Для расчета амортизации в системе реализованы следующие методы: Линейный метод (метод равномерного начисления). Нелинейный метод (для налогового учета). Метод уменьшаемого остатка. Метод с использованием суммы лет срока полезного использования объекта. Метод списания стоимости пропорционально объему выпущенной продукции. Метод расчета вручную (с использованием графика амортизации). Производство Для оптимизации производственного процесса система Axapta предлагает предприятию полнофункциональное решение для управления производством. Разработанный с учетом новейших технологий и в соответствии с международными и российскими стандартами, производственный контур является отдельной функциональной частью системы и состоит из нескольких модулей: 1. Модуль Управление запасами. В производственном контуре используется его функционал работы со спецификациями: Разработка, конфигурирование, расчет спецификаций Создание версий спецификаций Расчет потребления компонентов для производства спецификаций. 2. Модуль Производство. Центральный модуль контура, осуществляющий создание и управление производственными заказами: Планирование заданий и операций Расчет потребления Пошаговый мониторинг производственного процесса Калькуляция издержек и себестоимости произведенной продукции Создание маршрутов и версий маршрутов 3. Модуль Сводное планирование. Данный модуль позволяет оптимизировать производство на предприятии за счет совместного использования различных инструментов планирования и прогнозирования: Резервирование материалов и производственных мощностей 91 Прогнозирование, бюджетирование и автоматизированный расчет необходимых поставок. 1. 2. 3. 4. 5. 6. 7. 8. Контроль над складскими запасами и технологией производства любого типа. Информация о состоянии производственного запаса и его контроль. Расчет потребностей в необходимых для производства материалах. Регулирование процесса поставок комплектующих. Планирование производства с учетом любых изменений. Моделирование и конфигурация продукции. Составление маршрутов производства. Удобный интерфейс и гибкая система настройки. Производственные модули тесно взаимосвязаны между собой, а также с другими модулями системы, что обеспечивает надежную, эффективную и качественную работу всего предприятия: Управление проектами Система Axapta предоставляет прекрасные возможности для эффективного управления проектами разных типов. В модуле Проект проектирование осуществляется на основе методологии, принятой Международным Институтом Управления Проектами (www.pmi.org) с учетом следующих этапов: В Microsoft Dynamics AX (Microsoft Axapta) представлены проекты следующих типов: 1. Внутренние проекты. Внутренние проекты характеризуются затратами, возмещаемыми самим предприятием, так как проекты ведутся для решения внутренних проблем, как, например, регистрация времени, потраченного сотрудниками на обучение, отпуск или время болезни, а также затраты, связанные с проведением внутренних мероприятий (празднование Нового Года, семинары, выставки и т.д.). 2. Внешние проекты. Внешние проекты ведутся с целью получения предприятием прибыли и могут быть трех видов: Проекты типа «Время и расходы». В проектах этого типа (например, установка оборудования, проведение консультаций) цена не фиксируется, и счета выставляются по мере возникновения расходов и на основе цен на момент операции. При длительных проектах могут использоваться счета незавершенного производства и начисленной реализации. Проекты с фиксированной ценой. Цена подобного проекта ( например, установка систем программного обеспечения, строительство сооружений) фиксируется на этапе заключения контракта и отражается в планах платежей. Затраты по проекту не находят отражения в счетах. Соответственно, доходы не могут быть прямо соотнесены с расходами, и используются такие типы учета прибыли, как определение затрат и доходов только по завершению проекта и по каждому периоду. Проекты типа Сводка. Проекты типа «Сводка» служат для обобщения информации по нескольким проектам в один. По проектам типа «Сводка» нельзя регистрировать операции, что означает невозможность выставлять счета. 92 В распоряжении пользователя мощный инструмент планирования, ведения и анализа результатов проектов, позволяющий работать с проектами любой срочности и сложности: 1. возможность использовать данные из других модулей системы (например, справочники модуля Расчеты с клиентами или конфигурации номенклатурных единиц). 2. развитый графический инструментарий (возможность анализа данных на диаграмме Ганта). 3. широкий выбор статистических инструментов (статистика предоставляется различными способами: в общей форме, с помощью стандартных отчетов или сводных таблиц с использованием технологии OLAP). Внедрение модуля Проект предоставит предприятию ряд важных преимуществ, результатом которых станет слаженная работа компании, эффективное и своевременное выполнение задач, снижение издержек по проектированию: 1. Легкое управление сложными проектами обеспечивается их иерархической структурой, позволяющей работать одновременно с проектами любых типов и разбивать крупные проекты на более мелкие. Результатом становится быстрый и простой контроль и управление. 2. Удобное выставление счетов по проектам. Не надо вводить многократно данные по клиенту, можно выставлять счета сразу по нескольким проектам в разрезе одного Счета по проектам 3. Автоматический мониторинг и контроль затрат. За определения типа затрат (возмещаемые клиентом или самим предприятием) отвечает функционал Статуса отчетов. 4. Эффективное управление процессом реализации проекта. Система позволяет регистрировать часы, затраты, доходы и номенклатурные единицы по проектам, составлять графики работ для конкретных проектных групп, анализировать результат с помощью диаграмм Ганта. 93 ЛЕКЦИЯ №11 ТЕМА: Обзор ERP-систем «малого» класса. Обзор рынка систем. Основной функционал систем, на примере системы 1С или БОСС Описание интегрированного пакета «БОСС» «БОСС» компании АйТи является комплексной автоматизированной системой, разработанной для крупных корпораций, производственных и торговых объединений на базе Oracle7 Server. «БОСС-Корпорация» представляет собой комплекс программ, автоматизирующих определенные бизнес-процессы. Менее мощная система, у которой есть ограничения по количеству рабочих мест в сети – автоматизированная система «БОСС-Компания», реализованная на Scalable SQL Server фирмы Pervasive Software. Каждый её программный модуль может функционировать как отдельный продукт в течении длительного времени, но при необходимости, по желанию заказчика дополняется автоматизированными рабочими местами и интегрируется с другими модулями. «БОССКорпорация» – мощная многопользовательская система, которая может консолидировать данные модулей «БОСС-Компания». В процессе создания системы для крупной компании используются базовые модули системы, проводится детальное обследование, формирующее требования к составу систем оперативного сбора информации, документооборота, системы управления производством и финансами, проводится постановка задачи. Поэтому характерной особенностью системы является индивидуальность и четкая направленность на конкретного заказчика. Такой вариант интегрированной системы является заказным. Система «БОСС-Корпорация» состоит из базовых модулей и модулей, учитывающих специфику конкретных отраслей (рис. 4). Рис. 4. Модульная структура системы БОСС-КОРПОРАЦИЯ Базовые модули: 1. Администратор и нормативно-справочная информация; 2. Главная бухгалтерия (управление методологией ведения бухгалтерского учета, регистрация и контроль хозяйственных операций, формирование внутренней 94 3. 4. 5. 6. 7. 8. бухгалтерской и аналитической отчетности, формирование внешней бухгалтерской отчетности); Финансовое планирование (бюджетирование); Финансовый анализ; Финансовый контроллинг; Расчеты (управление безналичными и наличными денежными средствами, управление подотчетными суммами, расчеты с поставщиками, расчеты с покупателями); Основные средства; Управление персоналом (штатное расписание, учет кадров, зарплата). Отраслевые и специфические модули предназначенные для автоматизации следующих производственных процессов: 1. Управление проектами; 2. Управление производством; 3. Документооборот; 4. Управление закупками; 5. Управление запасами; 6. Реализация. Далее будут рассмотрены модули системы «БОСС-Компания», которые могут внедряться отдельно и интегрироваться в единую систему. Модуль Инструментальное средство разработки – «БОСС-Администратор». Модуль состоит из средства администрирования, словаря БД, средства разработки программ, средства запуска программ. Модуль обеспечивает разграничение прав доступа, поддерживает работоспособность системы, настройку, модификацию и развитие системы, администрирование и менеджмент словаря базы данных. Модуль Бухгалтерский учет и отчетность – «БОСС-Бухгалтер Модуль Бухгалтерский учет и отчетность – «БОСС-Бухгалтер» предназначен для ведения бухгалтерского учета и обеспечивает настройку системы на любой план счетов, ведение одновременно нескольких планов счетов, работу с несколькими Главными книгами, консолидацию баланса, поддержку неограниченного уровня аналитического учета и формирование различных аналитических категорий, ведение хозяйственных операций, работу с единичными проводками так и в пакетном режиме, поддержку любой схемы учета (мемориально-ордерная, журнально-ордерная, табличноавтоматизированную и др.), мультивалютный учет, отчетность в стандартах GAAP. Специализированные рабочие места модуля «БОСС-Бухгалтер» позволяют вести учет кассовых операций, учет операций на расчетных счетах, учет расчетов с подотчетными лицами, учет расчетов с контрагентами, учет основных средств, учет материальных ценностей, складской учет. Модуль Управление Финансами – «БОСС-Финансист» Модуль Управление Финансами – «БОСС-Финансист» предназначен для анализа денежных потоков, финансового прогнозирования и решает следующие задачи: разработка бюджета доходов и расходов, контроль движения денежных средств, ведение расчетов с покупателями и поставщиками, ведение расчетов с бюджетами, управление кредитами и инвестициями, операции с ценными бумагами. Модуль Контроллинг- «БОСС-Аналитик» предназначен для решения задач планирования, учета фактических затрат и финансового анализа и подготовке управленческих решений. 95 Решает следующие задачи: планирование прямых затрат на единицу выпускаемой продукции по всей номенклатуре на основании нормативов, формирование смет накладных расходов, распределение накладных расходов на единицу продукции, учет затрат (по статьям бюджетов и калькуляции, по объектам аналитики, по местам возникновения затрат), учет распределение накладных расходов по объектам аналитического учета, учет распределение расходов будущих периодов и предстоящих платежей, учет затрат в обслуживающих производствах и хозяйствах, сопоставление плановых показателей с фактическими затратами, расчет основных показателей финансово-хозяйственной деятельности. «БОСС-Аналитик» тесно взаимосвязан со всеми модулями информационной системы. Все модули системы являются источниками информации для управленческого учета. Система Управление персоналом - «БОСС-Кадровик» позволяет реализовать централизованную работу всех отделов предприятия, создать и поддерживать корпоративную структуру организации. Система состоит из модулей: Штатное расписание, Учет кадров, Расчет заработной платы. Модуль «Штатное расписание» предназначен для сотрудников плановоэкономического отдела и отвечает за корпоративную структуру предприятия и иерархию подчиненности структурных подразделений компании, поддержку штатного расписания всех структурных единиц предприятия и получение основных форм отчетности. Модуль «Учет кадров» отвечает за подготовку различных статистических данных и поддержку документооборота (приказы по персоналу, служебные записки, инструкции и т.д.). Модуль «Расчет заработной платы» предназначен для расчета заработной платы сотрудников и выполняет следующие расчетные функции: расчет зарплаты сотрудников компании, расчет аванса, расчет межрасчетных выплат штатным работникам, ведение архива ведомостей и лицевых счетов, автоматическая разноска зарплатных выплат по проводкам и статьям затрат, формирование документов для налоговых и других органов. Отраслевые модули системы «БОСС-Компания» Модуль Управление документооборотом – «БОСС-Референт» предназначен для управления документооборота и позволяет осуществлять централизованное хранение, поиск, пересылку документов любых форматов с разграничением доступа к ним. Разработан на базе продукта Lotus Notes фирмы Lotus Development Corporation. Модуль может функционировать как отдельная программа а также интегрироваться в систему управления предприятием «БОСС-Компания». Модуль поддерживает хранение информации о клиентах и партнерах, хранение образцов документов, планирование и контроль мероприятий и контрактов, составление, учет и контроль договоров. Модуль Управление производством - «БОСС-Технолог» предназначен для автоматизации процесса технологической проработке производства изделий, разработке и утверждении всего комплекта регламентирующих документов. Модуль позволяет определить состав и структуру изделий, вести проектно-конструкторскую документацию, проектировать технологические процессы, стыковать с модулем САПР, составлять план технической подготовки производства нового изделия, нормировать расход материальных и трудовых ресурсов. Модуль Управление сбытом «БОСС-Продавец» предназначен для отдела продаж и позволяет фиксировать контакты, учитывать заявки от покупателей, проводить анализ договоров, отгрузки товара и полученных оплат, контролировать ожидаемые отгрузки. Модуль решает следующие задачи: учет выпуска готовой продукции и товаров, учет готовой продукции товаров на складах, формирование договоров и счетов на поставку, 96 учет резервирования товаров на складах, расчет издержек реализации, поддержка сложных ценовых структур, формирование различных отчетных документов, ведомостей. Модуль Складской учет – «БОСС-Кладовщик» предназначен для контроля материальных ценностей в местах хранения и на всех стадиях обработки и позволяет документировать все операции по движению всех товарно-материальных ценностей, готовить данные для принятия хозяйственных решений. Модуль может работать со всеми удаленными складами. Модуль решает задачи: поступление товаров, материалов, МБП, отпуск товаров, материалов и МБП на сторону, в производство, материально ответственным лицам, возврат товаров, материалов и МБП, учет и движение тары, инвентаризация, учет, списание ТМЦ, ведение карточек складского учета, ведение ведомости материальных запасов, составление складского отчета. Модуль Управление снабжением – «БОСС-Снабженец» предназначен для снабжения предприятия сырьем и материалами, составления плана закупок ТМЦ, хранения информации о контрагентах. Модуль решает задачи: работа с планом закупок, ведение справочника поставщиков и производимых ими товаров, ведение справочников договоров с поставщиками, ведение учетной информации о наличии и использовании ТМЦ (по складам, материально ответственным лицам), отпуск ТМЦ сторонним организациям, ведение отчетной документации о деятельности отдела снабжения по всем разделам, ведение статистической отчетности по ГСМ. 97 ЛЕКЦИЯ №12 ТЕМА: Сравнительный анализ ERP-систем Введение В настоящее время все большую популярность приобретают системы планирования и управления ресурсами на предприятии. Такие системы предназначены для решения широчайшего спектра задач, начиная с задач учета материальных и человеческих ресурсов в одном подразделении предприятия, и заканчивая предоставлением информации для принятия стратегических управленческих решений в масштабе крупной промышленной корпорации. Использование информационных систем такого класса продиктовано сложностью управления предприятиями с развитой инфраструктурой, большим штатом и широкой территориальной распределенностью. Действительно, задача централизованного управления, планирования ресурсов и использования единых стандартов отчетности в рамках крупномасштабного предприятия под силу только высокоинтегрированным автоматизированным системам. Наиболее распространенным из современным стандартов информационных систем управления ресурсами на предприятии является стандарт ERP (Enterprise Resource Planning). Автоматизированные системы класса ERP, как правило, построены с использованием современных программных технологий и технических средств, обеспечивая тесную интеграцию не только между распределенными модулями системы, но и интеграцию с внешними системами, работающими на других предприятиях. Несмотря на большое разнообразие в масштабах ERP-систем (от десятков до тысяч поддерживаемых рабочих мест) спектр задач, решаемых такими автоматизированными системами, охватывает большую часть аспектов деятельности предприятия: учет и анализ хозяйственной деятельности; учет и анализ финансовых операций; управление основными средствами предприятия; планирование потребности в материальных ресурсах; учет и анализ сбытовой деятельности; управление человеческими ресурсами. Целью данного сравнительного анализа является выявление сходств и различий ERP-систем промышленного класса «BAAN IV», SAP/R3, «ORACLE APPLICATIONS», «Галактика» и «БОСС» по следующим аспектам: структуры и функциональности основных модулей систем; взаимодействия систем с другими средствами разработки; системных требований; внедрения. 98 Описание интегрированного пакета BAAN IV BAAN IV - интегрированная автоматизированная система, поддерживающая все направления бизнеса, включая финансы, производство, сбыт, снабжение, склады, транспортные перевозки, сервисное обслуживание и проектно-конструкторские работы. Основные блоки BAAN IV представлены на рис.1. Рис. 1. Основные блоки BAAN IV «Программные инструментальные средства» (BAAN IV Tools) Данный пакет обладает мощным инструментарием 4GL для создания новых и модификации существующих приложений. Инструментарий открыт для различных коммуникационных стандартов, баз данных, операционных систем и пользовательских интерфейсов, а также имеет мощный набор программных инструментальных средств, необходимых для развития, документирования, перевода и поддержки программного обеспечения. Подсистема «Производство» (BAAN IV Manufacturing) Подсистема "Производство" является комплексным решением для различных направлений производственной деятельности таких, как "конструирование на заказ", "сборка на заказ" и "изготовление на склад". В подсистему встроены улучшенный модуль планирования производственных ресурсов на уровне многозвенной корпорации (MPR II), конфигуратор продукта, модуль управления проектами и модуль анализа критических путей. На уровне многозвенной организации производства подсистема позволяет вести управление серийным выпуском продукции, отслеживать работу каждого подразделения и контролировать всю цепочку поставок. Подсистема содержит модули: Бюджет проекта, Изделие, Классификация продукта, Конструкторские данные, Конфигурация продукция, Общие данные, Основной производственный план, Потребности в материалах, Потребности в мощностях, Серийное производство, Система управления качеством, Спецификация изделия, Технологический маршрут, Учет времени, Учет затрат, Цеховое управление. 99 Подсистема «Сбыт, снабжение, склады» (BAAN IV Distribution) Подсистема представляет собой интегрированный комплекс по управлению сбытом, снабжением и складами. Включает в себя модули управления контрактами, товарно-материальными запасами и складским хозяйством, модули управления партиями изделий и их отслеживания, а также модуль электронного обмена данными. Также подсистема предусматривает возможность планирования потребностей в материальных потоках. Подсистема содержит модули: Изделие, Маркетинг и продажи, Общие данные, Пополнение запасов, Потребности распределения, Управление закупками, Управление запасами, Управление комиссионными скидками, Управление партиями, Управление продажами, Управление хранением, Учет затрат, Электронный обмен данными. Подсистема «Сервис» (BAAN IV Service) Подсистема «Сервис» предназначена для автоматизации процесса сервисного обслуживания и текущего ремонта, и включает в себя модули управления периодическим обслуживанием и текущим ремонтом, учета заявок, управления договорами на обслуживание, разработку графиков работ для специалистов и графиков обслуживания, а также модуль анализа затрат. Подсистема содержит модули: Основные данные, Управление установками, Контракты, Заказы на обслуживание, Анализ обслуживания. Подсистема «Финансы» (Finance) Подсистема «Финансы» позволяет работать с главной книгой, счетами дебиторов и кредиторов, осуществлять контроль и регулирование денежных операций, использовать электронные и другие методы учета платежей и поступлений. Подсистема оснащена усовершенствованной системой финансового планирования с использованием средств обращения к исходной информации, модулями функционального бухгалтерского учета и учета основных средств, отчетности и группировки компаний. Подсистема включает в себя модули: Главная книга, Общие данные, Счета кредиторов, Счета дебиторов, Управление денежными средствами, Распределение затрат, Основные средства, Система финансового плана, Финансовые отчеты. Подсистема «Транспорт» (BAAN IV Transportation) Подсистема позволяет автоматизировать внешние экспедиторские и транспортные услуги в рамках специализированных транспортных компаний, а также в рамках любых других фирм, пытающихся создать свои собственные транспортно-экспедиторские подразделения. Она включает в себя модули управления заказами на транспортировку и хранение, учета товарно-материальных запасов, автотранспорта и горюче-смазочных материалов. Подсистема позволяет рассчитывать стоимость фрахта, планировать погрузочно-разгрузочные работы и потребности в материальных потоках. Подсистема «Проект» (BAAN IV Project) Обеспечивает комплексное управление одновременно целым рядом проектов, а также их оценку. В подсистему входят усовершенствованный модуль планирования работ над проектами с их соответствующей разбивкой по этапам, модуль контроля хода выполнения проекта относительно плановых и оценочных показателей, который, среди 100 прочего, позволяет разрабатывать прогнозы, готовить счета-фактуры и вычислять доходы проекта. Подсистема включает в себя модули: Основные данные, Оценка проекта, Бюджет проекта, Бюджет проекта, Потребности проекта, Ход выполнения проекта, Фактурирование проекта, Мониторинг проекта. Подсистема «Организатор» (BAAN IV Organiser) Позволяет быстро и с минимальными усилиями внедрять любые продукты семейства BAAN IV. Пакет состоит из модуля «Анализатор бизнес-потока» (Business Flow Analyser), мультипрограммных инструментальных средств (Мultimedia Toolkit) для обучающих программ, информационной системы предприятия (Enterprise Information System), а также модуля отображения для количественной оценки результатов внедрения. 101 Описание интегрированного пакета «ORACLE APPLICATIONS» Oracle Applications компании Oracle – высокопроизводительная, многопользовательская интегрированная система учета, планирования и управления производством. Система разработана с использованием архитектуры клиент-сервер и средств компании Oracle. Система «Oracle Applications» состоит из основных комплексов, направленных на решение основных задач для полного функционирования компании: Финансы; Производство; Проекты; Человеческие ресурсы; Маркетинг; Логистика. Комплекс «Финансы» решает задачи управления основными фондами, финансового планирования, финансового анализа, консолидации, управления затратами, использования нескольких валют, управления денежными потоками. В комплексе «Финансы» используются и интегрируются приложения (модули): Финансовый анализ (Oracle Financial Analyzer); Главная книга (Oracle General Ledger); Закупки (Oracle Purchasing); Дебиторы (Oracle Receivables); Кредиторы (Oracle Payables); Основные фонды (Oracle Assets). Комплекс «Логистика» решает задачи управления качеством (анализ качества продукта на стадиях производства для удовлетворения потребностей потребителей), планирования (система распределенных планов, правил формирования, обработки, охватывающих все стадии жизненного цикла продукта: разработка, производство, реализация), управления снабжением (система поддерживающая бесперебойное снабжение предприятия сырьем и материалами), управления материальными потоками (система инвентаризации и распределения материалов на предприятии), управления продажами (система управления продажей продукции: комплектация заказов, ценовая политика, клиентская база), работы с клиентами. В комплексе «Логистика» используются приложения: Планирование (Oracle Supply Chain Planning); Master Scheduling/MRP; Управление материальными запасами (Oracle Inventory); Закупки (Oracle Purchasing); Кредиторы (Oracle Payables); Входящие счета (Oracle Order Entry); Товарная спецификация (Oracle Product Configurations); Дебиторы (Oracle Receivables); Обслуживание (Oracle Service); Качество (Oracle Quality). Комплекс «Производство» предназначен для решения задач по разработке новых продуктов, планирования и моделирования, управления материальными потоками, производства, управления себестоимостью, управления качеством. В комплексе «Производство» используются приложения: 102 Машиностроение (Oracle Engineering); Структура продукта (Oracle Product Configurator); Счета материалов (Oracle Bills of Material); Планирование материальных потоков (Oracle Supply Chain Planning); Oracle Master Scheduling/MRP; Производительность (Oracle Capacity); Управление материальными потоками (Oracle Inventory); Поставщики (Oracle Supplier Scheduling); Закупки (Oracle Purchasing); Незавершенное производство (Oracle Work in Process); Себестоимость (Oracle Сost Management); Качество (Oracle Quality); Oracle GEMMS. Комплекс «Проекты» предназначен для решения задач по управлению проектами (определение цены, определение бюджета), аккумуляции стоимости (определение стоимости проектов), нормирования и анализа трудоемкости проекта, определения источников для выполнения проекта, определение дохода и прибыли. В комплексе «Проекты» используются приложения: Определение стоимости проекта (Oracle Project Costing); Определение финансового результата от проектов (Oracle Project Billing); Нормирование и трудоемкость (Oracle Personal Time and Expense); Данные складского учета (Oracle Applications Data Warehouse). Комплекс «Человеческие ресурсы» предназначен для решения задач по поиску и найму на работу персонала, учета обучения и тренинга персонала, учета заработной платы, учета списочного состава сотрудников, организационного планирования. В комплексе «Человеческие ресурсы» используются приложения: Списочный состав (Oracle Payrole); Человеческие ресурсы (Oracle Human Resources); Развитие человеческих ресурсов (Oracle Training Administration); Выплаты зависящие от продаж (Oracle Sales Compensation). Комплекс «Управление рынком» предназначен для решения задач по поддержке управления продажами, управления маркетингом, анализа рынков, завоевания рынка, оперативной поддержки решений. В комплексе «Управление рынком» используются приложения: Финансовый анализ (Oracle Financial Analyser); Данные складского учета (Oracle Applications Data Warehouse); Продажи и маркетинг (Oracle Sales and Marketing); Выплаты зависящие от продаж (Oracle Sales Compensation); Приложения для internet (Oracle Applications for the Web). Каждое приложение (модуль) может использоваться отдельно. Благодаря единому словарю данных, используемому модулями, достигается полная интеграция между приложениями, и взаимосвязь всех бизнес-процессов протекающих в компании. Основные модули интегрированного пакета Oracle Applications: Модуль Главная книга (Oracle General Ledger) представляет собой систему управления финансами с полным набором средств, необходимых для контроля финансов, сбора данных, подготовки финансовой отчетности. 103 Модуль Дебиторы (Oracle Receivables) представляет систему управления расчетами с дебиторами. Модуль Кредиторы (Oracle Payables) – это система по учету и контролю расчетов с кредиторами, учетом всех форм скидок поставщиков. Модуль Закупки (Oracle Purchasing) – система управления закупками, необходимая для эффективной обработки заявок, заказов на приобретения, запросов предложения и поступлений. Модуль Основные фонды (Oracle Assets) – система управления активами, необходимая для правильной организации учета имущества и оптимального выбора стратегии учета и налогообложения. Модуль Управление материальными потоками (Oracle Inventory) – система управления материальными запасами в складском хозяйстве. Модуль Входящие счета (Oracle Order Entry) – модуль для сбытовых подразделений (ввод заказов и управление ими). Модуль Движение денежных средств (Oracle Cash Management) – мультивалютная система управления движением денежных средств. 104 Описание интегрированного пакета «Галактика» Система «Галактика» – многопользовательский сетевой комплекс полной автоматизации предприятий. Решение всего комплекса задач, на который ориентирован комплекс «Галактика», обеспечивается четырьмя функциональными контурами: контур административного управления, включающий в себя: управление маркетингом, финансовое планирование, хозяйственное планирование, управление проектами, учет и управление кадрами, анализ финансовой и хозяйственной деятельности, управление документооборотом; контур оперативного управления, включающий управление закупками (снабжение), складской учет, управление продажами (реализация), расчеты с поставщиками и получателями, ведение переговоров, управление консигнационным товаром, торговый зал, учет материальных ценностей в производстве; контур управления производством, включающий в себя: техникоэкономическое планирование, учет фактических затрат, оперативное управление производством, техническая подготовка производства; контур бухгалтерского учета, включающий в себя: учет МЦ, учет МБП, учет основных средств, расчет зарплаты, кассовые ФРО, валютные операции, мультивалютный учет, консолидированная финансовая и бухгалтерская отчетность. Модульный принцип построения комплекса «Галактика» допускает как изолированное использование отдельных программных модулей, так и их произвольные комбинации, в зависимости от производственно-экономической необходимости. 6.1 Контур административного управления Модуль «Управление маркетингом» Основные возможности модуля управления маркетингом: ведение расширенной информации о товарах, типовых услугах, регистрация и обработка контактов с потенциальными поставщиками, управление каналами сбыта, анализ рынка рекламных услуг, планирование рекламных компаний, размещение рекламы, анализ эффективности рекламных вложений, сбор и обработка независимых отзывов, ведение досье на фирмыконкуренты и товары-аналоги, анализ рынка предложений, управление ценовой политикой, контроль «жизненного» цикла товаров, анализ сегментов рынка, регистрация «серийных» продаж, учет рекламаций, гарантий, маркетинговый анализ сбыта в разрезах по каналам сбыта, товарам, группам товаров (услуг), направлениям реализации. Модуль «Финансовое планирование» Модуль «Финансовое планирование» предназначен для составления плана инвестиций капитала и связанных с этим затрат, а также для проведения контроля и анализа хода выполнения составленного плана. Основные возможности модуля: разработка структуры финансового плана, составление финансового плана в разрезе направлений деятельности как плана движения средств по периодам планирования в разрезе иерархии статей затрат и поступлений, проведение детального анализа составленного плана по направлениям деятельности и по подразделениям за весь период планирования или за выбранный отрезок времени, обобщение финансовых планов для отдельных направлений деятельности в единый финансовый план, проведение анализа влияния изменения курса базовой валюты и прогнозируемое изменение затрат и поступлений по статьям финансового плана, 105 регистрация хода выполнения финансового плана и разноска поступлений и затрат по направлениям деятельности и по подразделениям, контроль хода выполнения финансового плана за прошедший период на базе получения отчетов типа «план/факт». Модуль «Хозяйственное планирование, управление проектами» Программный модуль «Хозяйственное планирование, управление проектами» предназначен для решения задач управления деятельностью предприятия путем проведения планирования работ над проектами с последующим контролем исполнения утвержденных планов. Основные возможности модуля: составление планов подразделений и отдельных исполнителей в направлений деятельности, планирование необходимых ресурсов для выполнения намеченных планов, обобщение планов в единый хозяйственный план корпорации, увязка работ в единый календарно-сетевой график, формирование планов работ по исполнителям на любой период, регистрация хода выполнения планов, ведение журнала проведенных мероприятий, контроль исполнения планов администрацией, ведение документооборота в разрезе структуры хозяйственного плана. Модуль «Анализ финансовой и хозяйственной деятельности» Программный модуль «Анализ финансовой и хозяйственной деятельности» предназначен для обеспечения руководства набором наглядных графических и текстовых отчетов для быстрого обзора хозяйственно-финансового состояния предприятия и принятия управленческих решений. Основные возможности модуля: вертикальный анализ (структура) типовых форм отчетности в любой из накопленных моментов времени, горизонтальный анализ (динамика) типовых форм отчетности в любой из накопленных моментов времени, вертикальный и горизонтальный анализ типовых форм отчетности относительно выбранного базового момента времени, анализ динамики и структуры показателей хозяйственно-финансовой деятельности предприятия (оценка имущественного положения, ликвидности, финансовой устойчивости, деловой активности, рентабельности, положения предприятия на рынке ценных бумаг), анализ динамики превышения или занижения показателями хозяйственно-финансовой деятельности рекомендуемых значений, позволяющий сделать вывод о возможном ухудшении или улучшении хозяйственно-финансового состояния предприятия, создание и просмотр отчетов, производных от типовых форм, позволяющий группировать и соотносить рассчитанные значения практически по любой методике финансового менеджмента. Модуль «Учет и управление кадрами» Программный модуль «Учет и управление кадрами» предназначен для: автоматизации процесса ведения личных дел сотрудников, планирования и управления штатным расписанием и резервом на замещение должностей, планирования и учета рабочего времени сотрудников, получения отчетов по кадровой информации о сотрудниках. Модуль «Управление документооборотом» Программный модуль «Управление документооборотом» предназначен для учета, хранения и обработки документов и учетных карточек бумажных документов (договоров, писем, приказов, протоколов и др.) в электронной форме. Основные возможности модуля: создание и ведение номенклатуры дел, создание полнотекстных документов, создание классификации документов и использование ее в 106 процессе работы, ведение стадий обработки документов и контроль исполнения документов, поиск документов по формальным полям, присвоенных данному документу, массовая рассылка документов в подразделения, регистрация (постановка на учет) отчетов комплекса как документов. 6.2 Контур оперативного управления Модуль «Управление закупками» Программный модуль «Управление закупками» предназначен для отслеживания поступающих от подразделений заявок на приобретение, составление плана закупок в соответствии с заключенными договорами и долгосрочными контрактами, выбор конкретного поставщика и формирования заказа на поставку, регистрации документов, на основании которых производится закупка, оформления доверенностей на получение, распределения МЦ по складам, контроль состояния договоров и платежных документов на приобретение, получения отчетов в разрезе отслеживаемой номенклатуры, партий, групп, и используемых систем классификации. Основные возможности модуля: использование в документах на закупку как товарных, так и нематериальных позиций (услуг), учет партий закупаемых товаров, отслеживание сроков хранения, сроков действия лицензий и сертификатов, поддержка различных валют и международных закупок, учет таможенных пошлин, транспортных и прочих затрат при вычислении учетной стоимости конкретных закупаемых изделий, учет возвратов по рекламации, распределение товаров по складам, автоматическое формирование приходных складских ордеров по группе накладных, формирование платежных документов на оплату, формирование доверенностей на получение матценностей, отражение в бухгалтерском контуре всех операций по закупкам материальных ценностей и услуг, выдачу различных отчетов о закупаемых товарах и услугах в разрезе номенклатуры, поставщиков, групп, партий. Модуль «Управление продажами» Основные возможности модуля: автоматическое формирование номеров документов на продажу с возможностью их корректировки пользователем, учет типа налогообложения при оформлении документа, гибкая возможность изменения цен путем оперативной корректировки прайс-листов, использование в документах на продажу как товарных, так и нематериальных позиций (услуг), возможность формировать документ в любой из зарегистрированных в системе валют с расчетом рублевого или валютного эквивалента, возможность корректировки курса валюты непосредственно в процессе формирования документа, динамический контроль наличия товаров на складе при выписке счета, возможность управлять выбором склада, с которого должна произойти отгрузка, возможность автоматически оформлять накладную по выписанному документуоснованию, возможность автоматически производить списание товара на складе при оформлении накладной на его отпуск, учет возвратов ТМЦ, формирование платежных требований на оплату по документам-основаниям, прогнозирование объемов закупок и формирование заявок на дефициты, отражение в бухгалтерском контуре всех операций по реализации материальных ценностей и услуг с помощью механизма типовых хозяйственных операций. Модуль «Складской учет» 107 Программный модуль «Складской учет» тесно связан с задачами управления закупками и продажами. Основные возможности модуля: формирование приходных и расходных складских ордеров, распределение матценностей по материально-ответственным лицам, учет операций с ТМЦ с помощью карточки складского учета, операции внутреннего перемещения, динамический пересчет складских остатков, учет партий товаров, контроль сроков хранения партий, сроков действия сертификатов (лицензий), ведение учетных цен, поддержка методик списания по средневзвешенным ценам, LIFO, FIFO, формирование ведомостей наличия МЦ на любую дату в разрезах: склад, партия МЦ, инфраструктура склада, формирование накопительных ведомостей по приходам и расходам, контроль неликвидов, сверхнормативов, дефицитных позиций, проведение инвентаризации, формирование ведомости фактического наличия, сличительной ведомости по итогам инвентаризации, ведомости по рассогласованным позициям, проведение дооценки импортных товаров в связи с изменением курса валют. Модуль «Управление консигнационным товаром» Программный модуль «Управление консигнационным товаром» предназначен для приема и передачи товара с регламентной отсрочкой платежей по мере реализации. Основные возможности модуля: оформлять документы на прием или передачу консигнационного товара, передавать на консигнацию комплекты товаров, получать сведения о документах-основаниях по выбранным контрагентам с помощью карточки консигнатора и консигнанта, оформлять накладные на прием или возврат консигнационного товара, получать ведомости по реализации и ведомости остатков консигнационного товара, контролировать соответствие накладных и складских ордеров, учитывать расчеты между консигнантами и консигнаторами, получать отчеты по исполняемым документам-основаниям на прием или отпуск консигнационного товара. Модуль «Расчеты с поставщиками и получателями» Программный модуль «Расчеты с поставщиками и получателями» предназначен для полного контроля взаиморасчетов с контрагентами с учетом финансовых и товарных сопроводительных документов. Основные возможности модуля: формирование реестра исполняемых договоров с учетом товарных и финансовых документов по этим договорам, режим привязки платежных документов к договорам (документам-основаниям), автоматическое формирование платежных документов по документу-основанию, расчет сальдо и составление платежного баланса по контрагенту, контроль взаиморасчетов, начисление и учет штрафов (неустоек и пени) по невыполненным обязательствам контрагентов или фирмы. 6.3 Контур управления производствам Модуль «Технико-экономическое планирование» Программный модуль «Технико-экономическое планирование» предназначен для использования в планово-экономической службе предприятия. (ТЭП) Программный модуль решает 3 блока задач: 108 поддержка нормативно-справочной информации: состав выпускаемой продукции, специфицированные нормы расхода сырья, материалов в разрезе технологических операций и структурных подразделений, пооперационные технологические процессы (нормы времени, расценки, технологическое оборудование, инструмент, оснастка), планирование производства: формирование портфеля заказов, формирование плана производства на каждый месяц по номенклатуре и объему, пересчет производственных показателей при изменении плана, формирование производственной программы, формирование сбалансированного по ресурсам плана, оценка сводных потребностей в материалах и трудозатратах на производственный заказ, план производства, производственную программу, расчет плановой себестоимости: расчет нормативных затрат на производство, расчет свода затрат на производство, расчет сводных смет затрат по цехам и сметы затрат по предприятию, расчет нормативных калькуляций себестоимости изделий и полуфабрикатов на месяц по предприятию и в разрезе цехов, расчет плановых цен изделий на основе себестоимости. Модуль «Учет затрат на производство» Программный модуль «Учет затрат на производство» предназначен для расчета фактических затрат по итогам производственной деятельности предприятия за период. Программный модуль решает следующие задачи: учет фактических объемов выпуска: расчет по данным складских приходов фактического выпуска готовых изделий и полуфабрикатов по цехам за каждый месяц, учет фактических объемов незавершенного производства, расчет фактических затрат: расчет фактических смет расходов по комплексным статьям калькуляции, расчет сумм фактических прямых затрат по статьям калькуляции в разрезе подразделений и по предприятию, расчет сумм фактических затрат по экономическим элементам, расчет полных смет фактических затрат по подразделениям, расчет сметы и свода фактических затрат по предприятию, расчет калькуляций фактической себестоимости производственных заказов, расчет калькуляций фактической себестоимости изделий, расчет себестоимости незавершенного производства, контроль и анализ отклонений плановых и фактических затрат. Модуль «Техническая подготовка производства» Программный модуль «Техническая подготовка производства» предназначен для использования в конструкторских отделах, технологических, планово-экономических и планово-диспетчерских службах предприятия. Состав решаемых модулем задач: конструкторская подготовка производства: поддержка номенклатуры изделий, поддержка состава изделий (конструкторских спецификаций в стандарте ЕСКД), поддержка извещений на конструкторские изменения, технологическая подготовка производства: поддержка подетальноспецифицированных норм расхода материалов в разрезе технологических операций, поддержка пооперационных технологических процессов в стандартах ЕСТД, поддержка извещений на технологические изменения, расчетные функции: разузлование изделий, расчет потребностей в материальных ресурсах, расчет потребностей в трудовых ресурсах, расчет потребностей в оборудовании, оснастке, инструменте. 109 Модуль «Оперативное управление производством» Программный модуль «Оперативное управление производством» предназначен для использования в планово-диспетчерских службах предприятия. Основные функциями модуля: управление процессом запуска-выпуска продукции в соответствии с производственной программой и технологией производства, внутризаводская (межцеховая) диспетчеризация материальных потоков в производстве, оперативный учет выполнения производственной программы, детальный контроль незавершенного производства. 6.4 Контур бухгалтерского учета Модуль «Кассовые и финансово-расчетные операции» Модуль «Кассовые и финансово-расчетные операции» обеспечивает контроль соответствия платежей, оформленных финансовыми документами и сумм, указанных в документах-основаниях, а также получение баланса взаиморасчетов с контрагентами. Обеспечивается возможность автоматизированного ввода банковских выписок в виде текстовых файлов, пересылаемых модемной связью или на дискетах, а также выполнение электронных платежей. Проводки по финансовым документам могут быть сформированы с помощью типовых хозяйственных операций. Предусмотрена возможность ведения учета не только в национальной денежной единице, но и в иностранных валютах. Модуль «Расчет зарплаты» Модуль «Расчет зарплаты» полностью автоматизирует ведение табелей и расчет начислений, удержаний и налогов на фонд оплаты труда при повременной и сдельной форме оплаты. Учтены особенности расчетов по оплате труда, включая изменение минимальной заработной платы, видов и ставок налогов, индексацию. Предусмотрена возможность использования районных коэффициентов, северных надбавок, доплаты за выслугу лет. Автоматизирован расчет аванса, пособий матерям, больничных, отпускных, пособий на детей, разовых выплат, индивидуальных и бригадных подрядов, договоров подряда. Учет основных средств и нематериальных активов Учет основных средств и нематериальных активов обеспечивает ведение картотеки ОС и НМА, расчет амортизации за месяц, формирование проводок, переоценку ОС, формирование отчетов. Главная книга. Баланс Формирование Главной книги заключается в выборе записей по входящим сальдо и по всем проводкам и в расчете оборотов и исходящих остатков по счетам бухгалтерского учета. Алгоритм расчета Баланса предприятия и приложений к нему не является строго предопределенным. Поэтому все выходные отчетные бухгалтерские формы поставляются в открытом виде (т.е. вместе с исходными формулами расчета), доступными для коррекции пользователем. Состав стандартных отчетных бухгалтерских форм полностью соответствует текущим требованиям законодательства России. 110 Консолидированная отчетность корпорации С помощью модуля «Консолидация» реализуется возможность ведения параллельного учета в нескольких планах счетов бухгалтерского учета, т.е. многоплановость счетов, обеспечивается возможность ведения консолидированной (совместной) базы данных корпорации и получения консолидированной отчетности. 111 8. Сравнительный анализ ERP-систем с точки зрения стандартов управления предприятием. В данном разделе представлены основные отличия в функциональностях стандартов управления предприятием, описанных выше, а также проведен анализ функций ERP-систем, с точки зрения удовлетворения этим стандартам. Сразу можно сказать, что ни одна из рассматриваемых систем не имеет функциональности стандарта CSRP, поэтому, анализ проводился лишь для стандартов MRP-ERP. ERP-система Критерий ГалактикаПарус (Россия) АЙ-ТИ (Россия) SAP AG (Германия) BAAN Company (Голландия) ORACLE (США) Галактика (Oracleверсия) БОССКорпорация R/3 Baan IV Oracle Applications Функции стандартов MRP/CRP Формирование графика поставок Распределение производственных работ во времени + + + + + + + + + + Функции стандарта MRP II Формирование планаграфика распределения денежных средств Контроль и корректировка выполнения производственного, оперативного и финансового планов + + + + + + + + + + Функции стандарта ERP Планирование для любого типа производства Возможность многоуровнего производственного планирования Планирование и учет финансов на уровне корпорации Возможность планирования ресурсов для всех подразделений компании (техобслуживание, одиночные проекты) Возможность использования средств поддержки принятия решений - - + + - + + + + + + + + + + - - + + + - - + + + Табл. 1. Сравнительный анализ функций систем с точки зрения стандартов управления предприятием. 112 Как видно из табл. 1. западные системы обладают большей функциональностью, чем отечественные разработки. Т.к. стандарт ERP не утвержден, вопрос об отнесении системы к классу ERP, остается открытым и рассматривается различными специалистами по разному. Набор функциональности систем растет от версии к версии, в современных системах начинают появляться функции стандарта CSRP, при внедрении некоторые функции реализуются дополнительно, все это делает границу между ERP и MRP II системами все более размытыми. Следует также отметить, что набор функциональности является важным, но далеко не определяющим фактором при выборе внедряемой системы. Следует также принимать внимание степень локализации системы, уровень технической поддержи при внедрении и после него, стоимость и сроки внедрения, и множество других аспектов. 113 Заключение Выбор ERP-системы - многокритериальная задача, для выбора должны быть заданы объективные критерии, по которым будет осуществляться выбор конкретной системы: Функциональные возможности; Степень защищенности; Стоимость системы; Перспективы развития, поддержки и интеграции; Используемое общесистемное программное и аппаратное обеспечение; Опыт предыдущих внедрений; Масштабы и сроки внедрения. Набор критериев выбора системы не ограничивается вышеуказанным списком, для каждого предприятия такой набор индивидуален, и, как правило, включает дополнительные критерии, зависящие от специфики конкретного предприятия, таких как необходимость консолидации информации структурных подразделений, ведения учета одновременно по российским и международным стандартам и т.п. При выборе той или иной системы для предприятия необходимо знать и понимать цели внедрения автоматизированной системы, именно они определяют требуемую функциональность системы. Следует отметить, что любая из автоматизированных систем - лишь инструмент для повышения эффективности управления и учета, принятия правильных стратегических решений, который не будет эффективным, при отсутствии надлежащего функционального и организационного обеспечения. 114 115 Приложение. Сравнительный анализ ERP-систем с точки зрения внедрения ERP-система Критерий Стоимость лицензии на 400 пользователей ($ тыс.) Оценка срока полного внедрения (лет) Наличие встроенных средств построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм Возможность быстрой перенастройки системы во время внедрения ГалактикаПарус (Россия) АЙ-ТИ (Россия) SAP AG (Германия) BAAN Company (Голландия) ORACLE (США) Галактика (Oracleверсия) БОССКорпорация R/3 Baan IV Oracle Applications 1200 900 2 1,5 1-1.5 + + + + + + Стоимость и сроки создания системы 700 800 1700 3 - - 2,5 Простота внедрения - - Простота обучения и работы с системой Обучение: - на рабочем месте, - у поставщика, - у третьих компаний. Стандартизация клавиш и стиля экранных форм Возможности формирования: - меню, - экранных форм, - отчетов. Многоплатформенность клиентской части (графическая, алфавитноцифровая) Описание цепочек событий и связанных с ними инициируемых действий Описание маршрутов движения документов по рабочим местам (исполнителям) Мультивалютность Комплексность услуг фирмы (СУБД +Инструментальные средства+Приложения) Отчетность в GAAP,IAS + + + + + + + н/д + + + + + + + + + + + + + + + + + + + + + + + + + + + Гибкость настройки и модификации + - - + + + + + + + + + Дополнительные возможности + + - + - + + + + + - + + + 116 Поддержка международных стандартов в финансовохозяйственной деятельности предприятий СУБД + Btrieve, Oracle Операционная (клиент) система Операционная (сеть) система Аппаратная платформа + + Общесистемное ПО Scalable SQL Oracle, Server Informix, (Btrieve), Sybase,DB2,S Oracle QL Server DOS, Windows 95 Windows, OS/2 DOS, Windows 3.11, Windows 95, Windows NT Novell Novell Unix, Netware, Netware, Windows NT Windows NT Solaris Аппаратная платформа Intel,HPIntel,HPIntel,HP9000,AS/ 9000,AS/ 9000,AS/ 400,MainFra 400,MainFra 400,MainFra me,DEC me,DEC me,DEC ALFA,SUN ALFA,SUN ALFA,SUN SPARC SPARC SPARC + + BAAN Base, Oracle, Informix, Sybase DOS, Windows 95 Oracle DOS, Windows 95 Unix, Windows NT Unix, Windows NT Intel,HP9000,AS/ 400,MainFra me,DEC ALFA,SUN SPARC Intel,HP9000,AS/ 400,MainFra me,DEC ALFA,SUN SPARC Лабораторные работы 1 Разработка Устава проекта на внедрение КИС, план-графика внедрения в Project. 2 Проектирование КИС на базе CASE-средства AllFussion Process Modeler. Разработка моделей бизнес-процессов: DFD. 3 Проектирование КИС на базе CASE-средства ARIS. Основы администрирования ARIS. Проектирование на организационном уровне представления (Organization chart). 4 Проектирование КИС на базе CASE-средства ARIS. Проектирование на функциональном уровне представления (Function tree). 5 Проектирование КИС на базе CASE-средства ARIS. Проектирование на процессном уровне представления (EPC). 6 Проектирование КИС на базе CASE-средства ARIS. Проектирование на уровне представления данных (ERD). 8 Основы работы с системами класса ERP, на примере Microsoft DynamicsAx. Основы администрирование Microsoft DynamicsAx. 9 Основы работы с системами класса ERP, на примере Microsoft DynamicsAx. Финансовый контур Microsoft DynamicsAx. 10 Основы работы с системами класса ERP, на примере Microsoft DynamicsAx. Логистический контур Microsoft DynamicsAx. 11 Основы работы с системами класса ERP, на примере Microsoft DynamicsAx. Производственный контур Microsoft DynamicsAx. Курсовой проект 1 Разработка концепции внедрения КИС на базе Microsoft DynamicsAx для предложенного предприятия. 117 Буч Г., Рамбо Д., Джекобсон А. Язык UML: Руководство пользователя: Пер. с англ. – М.: ДМК, 2000. – 432 с. 2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с. 3. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнеса». – М.: СИНТЕГ, 2000, 212 с. 4. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. М.: Весть-Метатехнология, 2001 5. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование: Пер. с англ. – М.: ДМК Пресс, 2001. – 176 с. 6. Ларман К. Применение UML и шаблонов проектирования. Введение в объектно – ориентированный анализ и проектирование :Пер. с англ. – М.: Издательский дом «Вильямс», 2001. -496 с. 7. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001 – 304 с. 8. В. Репин, С. Маклаков ARIS Toolset/BPwin: выбор за аналитиком. http://www.compress.ru/Temp/2878/index.htm 9. С.Д.Паронджанов, Компания Аргуссофт Методология создания корпоративных ИС. - http://www.neic.nsk.su/rus/tech/cit/kbd96/43.htm 10. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник.-М.: Финансы и статистика, 2002.-512 с. 11. Шеер А.-В. Бизнес-процессы. Основные понятия. Теория. Методы. — М.: ВестьМетаТехнология, 1999. 12. Хотяшов Э. Н. Основы проектирования систем машинной обработки данных. – М.: ФиС, 1981. 1. 118
