'

Моделирование, реорганизация и автоматизация бизнес-процессов

Понравилась презентация – покажи это...





Слайд 0

Моделирование, реорганизация и автоматизация бизнес-процессов Калянов Георгий Николаевич доктор технических наук, профессор, зав. лабораторией ИПУ РАН, зав.кафедрой МФТИ kalyanov@mail.ru, www.kalyanov.by.ru


Слайд 1

Управление предприятием с использованием ИТ


Слайд 2

ИТ и ИС В современных условиях под информационной технологией (ИТ) понимается регламентированный бизнес-процесс, поддержанный (полностью или частично) информационной (автоматизированной) системой. В соответствии с ГОСТ Р ИСО/МЭК ТО 10000-1-99 ИС предназначена “для сбора, передачи, обработки, хранения и выдачи информации потребителям” и состоит из следующих основных компонентов: “программного обеспечения, информационного обеспечения, технических средств, обслуживающего персонала”.


Слайд 3

Схема управления


Слайд 4

Особенности ИТ относится к классу организационно-технических систем одновременно является объектом управления и частью управляющей системы в процессе управления предприятием с использованием ИТ участвуют следующие системы: производственная система (в качестве целевого объекта управления); система управления предприятием; ИТ как часть системы управления предприятием; ИС как часть ИТ; система управления ИС.


Слайд 5

Определение системы (Волкова В.Н.) S = <z, str, tech, cond>, где z – совокупность целей, str – совокупность структур, реализующих цели, tech – совокупность технологий, реализующих систему, cond – совокупность условий существования системы.


Слайд 6

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


Слайд 7

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


Слайд 8

ИТ цели ИТ (как части системы управления предприятием) направлены на решение задач управления бизнес-процессами, к реализующим цели структурам относятся процессные регламенты, бизнес-подразделения – пользователи ИТ, подразделения ИТ-службы, осуществляющие поддержку ИТ, в качестве реализующих систему технологий, как правило, рекомендуются эталонные модели управления ИТ-услугами, например, ITIL/ITSM.


Слайд 9

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


Слайд 10

Управление предприятием с использованием ИТ Лаборатория ИПУ – методов автоматизации управления организационными системами Кафедра МФТИ “Системный анализ и управление в области ИТ” Учебник “Моделирование, анализ, реорганизация и автоматизация бизнес-процессов”, ФиС, 2006. Учебник “Управление развитием информационных систем”, Горячая линия – Телеком, 2008г.


Слайд 11

Объекты профессиональной деятельности информационные системы и технологии; архитектуры предприятий и функциональные модели предметной области; функциональные и информационные системные модели; ИТ-процессы; ИТ-проекты.


Слайд 12

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


Слайд 13

Основные результаты Методология реорганизации бизнес-процессов модель бизнес-процесса метод инжиниринга бизнес-процесса метод тестирования бизнес-процесса метод оценки качества бизнес-процесса Методология управления ИТ-проектами Методология ИТ-консалтинга


Слайд 14

Специализация “Системный анализ и управление информационными системами” МФТИ – факультет информационных бизнес-систем (ФИБС) Направление 220100.68 “Системный анализ и управление” Квалификация – магистр техники и технологии Состав - Теоретические основы анализа и управления ИС. Архитектурный подход к управлению ИС и ИТ. Управление развитием ИС. Классификация ИС. Методы моделирования ИС. Проектирование ИС. CASE-технологии. Технологии управления данными и знаниями. Процессы управления ИТ-услугами. Стандартизация в ИТ-области.


Слайд 15

План Моделирование, реорганизация и автоматизация бизнес-процессов Введение - Бизнес и ИТ, ИТ-консалтинг Моделирование бизнес-процессов (методы, этапы проекта) Реорганизация бизнес-процессов Автоматизация бизнес-процессов Концепция архитектуры предприятия ТОП – методология реорганизации


Слайд 16

Бизнес и ИТ


Слайд 17

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


Слайд 18

Революция в бизнесе – переход к процессному подходу Совокупность различных видов деятельности, в рамках которой "на входе" используются один или более видов ресурсов, и в результате на "выходе" создается продукт, представляющий ценность для потребителя (Хаммер, Чампи). Структурированное конечное множество действий, спроектированных для производства специфической услуги (продукта) для конкретного потребителя или рынка (Давенпорт). Логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как продукт или услуга (Зиндер). Горизонтальная иерархия внутренних и зависимых между собой функциональных действий, конечной целью которых является выпуск продукции или отдельных ее компонентов (Верников). Связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (вещественный или нематериальный результат человеческого труда: предмет, услуга, научное открытие, идея), представляющий ценность для потребителя. (Калашян, Калянов)


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

Три этапа эволюции роли ИТ в развитии бизнеса Первый этап: 60 -70 г.г. Средства вычислительной техники и автоматизации управления жестко отделены от развития основной деятельности компаний Они рассматривались руководством как вспомогательные службы и представляли собой объект, связанный исключительно с затратами Второй этап: 80 - 95 г.г. Развитие и сближение деловых и технологических стратегий ИТ поддерживают инициативы и программы развития компаний Третий этап: 1996-н/вр Решающая роль ИТ в создании конкурентного преимущества компаний.


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

Управленческий консалтинг По классификации Европейской федерации ассоциаций консультантов по экономике и управлению (ФЕАКО) - более 100 видов консалтинга Управление - любое целенаправленное воздействие на предприятие, как на систему, приводящее к ее планомерному изменению для достижения максимальной эффективности или создания на ее базе новой системы путем заданной цепи изменений Управленческий консалтинг “заключается в предоставлении независимых советов и помощи по вопросам управления, включая определение и оценку проблем и/или возможностей, рекомендации соответствующих мер и помощь в их реализации” (ФЕАКО) Многофункциональный и междисциплинарный характер


Слайд 28

Виды услуг консалтингового процесса “Решение проблем бизнеса посредством современных информационных технологий” Стратегия развития предприятия Система управления предприятием Процессная структура предприятия Корпоративная информационно-управляющая система (КИУС)


Слайд 29

Стратегия развития предприятия ситуационный анализ (стратегическая позиция, сегменты рынка, позиционный анализ) формирование миссии и стратегических целей разработка корпоративной стратегии и философии бизнес-планирование выявление и моделирование бизнес-процессов разработка стратегии развития информационных технологий


Слайд 30

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


Слайд 31

Процессная структура предприятия инжиниринг/реинжиниринг процессов реорганизация оргструктуры оптимизация документооборота формирование должностных инструкций и положений о подразделениях реструктуризация ИТ-службы предприятия


Слайд 32

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


Слайд 33

Три основных этапа консалтингового проекта (оказания услуги) диагностика или выявление проблем (сбор данных и их обработку, определение проблемы) выработка решения (определение диапазона допустимых решений, выбор решения, презентация и согласование решения) внедрение решения (разработка программы внедрения, управление процессом внедрения, оценка результатов проекта)


Слайд 34

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


Слайд 35

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


Слайд 36

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


Слайд 37

Пример технологии


Слайд 38

Моделирование бизнес-процессов “Все модели неправильны. Некоторые модели полезны.”


Слайд 39

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


Слайд 40

Участники процесса моделирования Субъект –инициатор моделирования и/или пользователь его результатов Объект-оригинал – предмет моделирования, т.е. та система, которую хочет создать и/или использовать субъект Модель – образ, отображение оригинала Среда – окружение, в котором находятся и с которым взаимодействуют все участники


Слайд 41

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


Слайд 42

Требования, предъявляемые к моделям Ингерентность – достаточная степень согласованности создаваемой модели со средой (при этом не только модель должна приспосабливаться к среде, но и среду необходимо приспосабливать к будущей системе) Простота – модель используется как рабочий инструмент, который должен быть обозрим и понятен, доступен каждому участнику) Адекватность – возможность с помощью модели достичь поставленной цели в соответствии с сформулированными критериями (адекватна=полна+точна+истинна)


Слайд 43

ИнфоБизнес, № 14, от 10.04.2001 г. “Российская фирма, в которой не описаны бизнес-процессы, теряет около 20% товарооборота” (руководитель торгово-производственного холдинга “Руссо”)


Слайд 44

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


Слайд 45

Модель – основа для выполнения проектов следующих видов: Разработка стратегии развития ИТ Реорганизация бизнес-процессов Создание системы качества Формирование требований к КИУС Анализ рынка и выбор тиражируемых компонент КИУС Разработка ТЗ на создание и/или внедрение компонент КИУС Создание единой базы знаний по функциям и должностным обязанностям специалистов


Слайд 46

Требования к моделированию Контекст процессов, а не отдельных служб и подразделений (процессный подход) Структура всего предприятия с целью дальнейшего развития модели Интеграция функциональной, информационной и, возможно, поведенческой компонент Глубина проработки – до уровня функций/операций каждого должностного лица, до отдельных полей каждого документа


Слайд 47

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


Слайд 48

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


Слайд 49

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


Слайд 50

Классификация ·        основные процессы ·        сопутствующие процессы ·        вспомогательные процессы ·        обеспечивающие процессы ·        процессы управления ·        процессы развития


Слайд 51

“Создание программного обеспечения всегда включает в себя существенные задачи – моделирование сложных концептуальных структур, составляющих абстрактный программный объект, и второстепенные задачи – создание представлений этих абстрактных объектов с помощью языков программирования …” Фредерик Брукс


Слайд 52

Методы и языки моделирования бизнес-процессов


Слайд 53

Методы моделирования структурные объектно-ориентированные специальные


Слайд 54

Идеи, лежащие в основе структурных методов “черный ящик” иерархия графическая нотация


Слайд 55

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


Слайд 56

Средства структурного системного анализа Иллюстрируют: выполняемые функции отношения между данными динамическое поведение


Слайд 57

Средства структурного системного анализа DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов (миниспецификациями) или SADT (IDEF0) - диаграммы ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь" STD (State Transition Diagrams) - диаграммы переходов состояний


Слайд 58

Модельные связи


Слайд 59

DFD-диаграмма


Слайд 60

Спецификация процесса МС: Покупка лотерейных билетов Для каждого клиента выполняется проверка наличия требуемого числа билетов лотереи заполнение приходного кассового ордера (Форма 53) и занесение его в НД ДОКУМЕНТЫ ДНЯ ФИЛИАЛА прием наличных денег и занесение операции в НД БАНКОВСКИЕ ОПЕРАЦИИ (при этом осуществляются проводки: Д-т 54, К-т 207) выдача билетов лотереи


Слайд 61

SADT-диаграмма


Слайд 62

ERD - диаграмма


Слайд 63

Классификация методологий структурного системного анализа по отношению к школам - Software Engineering (SE) и Information Engineering (IE); по порядку построения модели - функционально-ориентированные и информационно-ориентированные; по типу целевых систем - для систем реального времени (СРВ) и для информационных систем (ИС).


Слайд 64

Наиболее часто используемые методологии


Слайд 65

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


Слайд 66

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


Слайд 67

Адекватность SADT – хорошо специфицированные и стандартизованные западные бизнес-процессы, DFD – слабая типизация бизнес-процессов, их стихийное появление и развитие наличие миниспецификаций DFD-процессов позволяет преодолеть логическую незавершенность SADT ограничения SADT (6-7 блоков на диаграмме) ведут к неестественному увеличению модели и в ряде случаев затрудняют ее читабельность и понимаемость


Слайд 68

Согласованность и интеграция


Слайд 69

Инструментальная поддержка До 10% CASE-средств поддерживают SADT, более 80% - различные нотации DFD (материалы CASE Consulting Group) 3% CASE-средств поддерживают SADT, 94% - различные нотации DFD (данные на основе анализа 167 CASE-пакетов)


Слайд 70

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


Слайд 71

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


Слайд 72

Пример business-use-case


Слайд 73

Специальные методы структурные карты (стандарты ANSI и ISO) схемы Харрингтона (Harrington), демонстрирующие структуру бизнес-процесса схемы процесса, базирующиеся на стандарте ANSI и включающие в себя такие объекты как: операция транспортировка инспекция хранение задержка


Слайд 74

Бизнес-моделирование и ARIS Organizational Chart - организационная схема Value Added Chain Diagram – VACD-диаграмма Function Tree - дерево функций extended Event-Driven Process Chain - eEPC-диаграмма Office Process - презентационная диаграмма.


Слайд 75

Организационная схема


Слайд 76

VACD-диаграмма


Слайд 77

Дерево функций


Слайд 78

eEPC-диаграмма


Слайд 79

Презентационная диаграмма (аналог eEPC-диаграммы)


Слайд 80

Выбор методологии моделирования бизнес-процессов Структурный системный анализ и проектирование Объектно-ориентированный анализ и проектирование Специальные методы Функционально-ориентированные Информационно-ориентированные DFD SADT


Слайд 81

Мифы Cтруктурный или объектно-ориентированный подход? Первичность функциональной или информационной модели? Функциональная модель – диаграммы потоков данных или IDEF0-диаграммы?


Слайд 82

Этапы моделирования


Слайд 83

Этапы проекта по моделированию Обучение группы аналитиков предприятия с целью дальнейшего их использования в ИТ-отделе и отделе развития Диагностика предприятия Построение моделей Анализ результатов и формирование предложений о необходимости изменений


Слайд 84

Этапы обучения Обучение основам методологии выполнения комплекса работ, связанных с построением и анализом моделей, реорганизацией, формированием и контролем требований к КИС (лекции, изучение инструментария, практические занятия) Аттестация группы аналитиков с выдачей сертификата Участие группы аналитиков в выполнении комплекса работ (передача технологий и методик)


Слайд 85

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


Слайд 86

Методы анкетирование сбор документов интервьюирование


Слайд 87

Анкетирование адресность размер: 1-2 страницы подпись анкетируемого приложение форм документов


Слайд 88

Сбор документов Структурированный альбом форм документов – хороший вспомогательный результат проекта


Слайд 89

Интервьюирование – как? Тезис в начале беседы - я ничего (или почти ничего) не знаю о Вашей работе, расскажите как можно подробнее, чем Вы занимаетесь? Правило 1 - если Вам начали подробно рассказывать технологию работы, ни в коем случае не перебивайте, необходимые уточнения можно сделать и в конце беседы. Правило 2 - если в беседе участвуют несколько аналитиков, вести беседу и задавать уточняющие вопросы должен один из них, неясные для других вопросы проясняются в конце беседы. Правило 3 - даже если Вы прекрасно знаете предметную область, не говорите много сами и не учите интервьюируемого: в любом случае выявляются тонкости и детали, специфичные для данного предприятия и, естественно, Вам неизвестные.


Слайд 90

Интервьюирование – у кого? “отказник” “говорун” “балласт” “экзотическеая должность” “мелкая сошка”


Слайд 91

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


Слайд 92

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


Слайд 93

Глубина проработки моделей


Слайд 94

Принципы структурирования в соответствии с деятельностями и бизнес-процессами предприятия, а не в соответствии с его оргштатной структурой верхний уровень модели должен отражать только контекст системы на втором уровне модели должны быть отражены основные деятельности предприятия и их взаимосвязи каждая из деятельностей, в свою очередь, должна быть детализирована на бизнес-процессы (желательно, единственного уровня) дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций (обычно 2-3 уровня) общее число уровней в модели не должно превышать 6-7 необходимо выполнять “правило накопителей”


Слайд 95

Классификация ·        основные процессы ·        сопутствующие процессы ·        вспомогательные процессы ·        обеспечивающие процессы ·        процессы управления ·        процессы развития


Слайд 96

ГОК: контекстная диаграмма


Слайд 97

Автобаза: диаграмма уровня деятельностей


Слайд 98

Ремонт и ТО: диаграмма бизнес-процессов


Слайд 99

Ремонт: диаграмма бизнес-функций


Слайд 100

Учет ремонта: диаграмма бизнес-функций


Слайд 101

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


Слайд 102

Реорганизация бизнес-процессов: подходы, проблемы, перспективы


Слайд 103

Актуальность проблемы спрос на соответствующие работы в рамках проектов создания КИУС отсутствие серьезного опыта выполнения проектов по реорганизации бизнес-процессов появление суррогатных методологий


Слайд 104

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


Слайд 105

Зачем заниматься реорганизацией? Устранить “узкие места“ в организации бизнес-процессов Повысить качество работы с клиентами Соответствовать новым условиям работы и требованиям рынка Использовать потенциальные возможности предприятия Обеспечить высокий уровень конкурентоспособности


Слайд 106

“Сегодня любая компания может оказаться вытесненной из бизнеса, если не сумеет вовремя приспособиться... Бывает, понимание необходимости преобразований приходит слишком поздно.” Билл Гейтс, Microsoft


Слайд 107

“Истинно великая компания охотно отказывается от установившейся практики, которая всегда приносила хорошие результаты, в надежде и расчете на нечто лучшее...” М. Хаммер, Д. Чампи “Реорганизация корпорации“


Слайд 108

Подходы к реорганизации BSP (business system plannig) - IBM, Мартин CPI (continuous process improvement) - Деминг TQM (total quality management) – японский вариант CPI CMM (capability maturity model for software) – “TQM для ПО” BPR (business process reengineering) - Хаммер, Чампи Первый проект по реорганизации был выполнен в середине 20-х годов


Слайд 109

Эволюционный и революционный подходы 2 варианта проверки кредитоспособности клиента Автобаза – путевой лист Диспетчерская служба ГОК


Слайд 110

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


Слайд 111

14 принципов Деминга Постоянное совершенствование товара или услуги Следование новой философии производства Отказ от массового контроля Установление долгосрочных партнерских отношений Постоянное совершенствование системы производства и обслуживания Обучение руководства Функция руководителя – руководство, а не надзор


Слайд 112

14 принципов Деминга 8) Устранение страха 9) Разрушение барьеров между подразделениями 10) Отмена лозунгов 11) Отказ от количественных показателей 12) Поддержка профессиональной гордости 13) Поощрение образование и совершенствования 14) Необходимые действия для осуществления изменений


Слайд 113

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


Слайд 114

BPR – характеристики “хороших” процессов Несколько работ объединяются в одну Исполнители принимают решение Этапы процесса выполняются в естественном порядке Существуют различные версии процесса Работа выполняется там, где ее целесообразно делать Снижение доли работ по проверке и контролю Минимизация согласований Единственная точка контакта Сочетание централизованных и децентрализованных операций


Слайд 115

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


Слайд 116

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


Слайд 117

ТОП - методология реорганизации бизнес-процессов планирование (проектирование) тестирование оценка качества


Слайд 118

ТОП методология планирования бизнес-процесса – обеспечивает анализ полного множества вариантов его исполнения методология тестирования бизнес-процесса – обеспечивает обнаружение ошибок на этапе создания методология оценки качества бизнес-процесса – обеспечивает адекватную оценку на основе введенных метрик


Слайд 119

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


Слайд 120

Состояние дел в области стандартизации Стандарты де-факто: DFD, ERD, STD, сети Петри Семейство IDEF (Integrated Computer Automated Manufacturing Definition): IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4 OMG UML 2.0 (UML Superstructure) Р 50-1-028-2001. Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования


Слайд 121

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


Слайд 122

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


Слайд 123

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


Слайд 124

Пример2: комплекс корпоративных стандартов проекта по моделированию бизнес-процессов общеинформационный документ по проекту описание языка моделирования описание методики построения моделей описание требований к результату моделирования описание необходимой функциональности инструментария описание отчетных форм и форм анкет


Слайд 125

Автоматизация бизнес-процессов


Слайд 126

Система (на современном этапе) “комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям” “в процессе функционирования автоматизированная система представляет собой совокупность комплекса средств автоматизации, организационно-методических и технологических документов и специалистов, использующих их в процессе своей профессиональной деятельности” (ГОСТ 34.003-90. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения)


Слайд 127

Информационная система ИС - система, предназначенная “для сбора, передачи, обработки, хранения и выдачи информации потребителям и состоящая из следующих основных компонентов: программное обеспечение; информационное обеспечение; технические средства; обслуживающий персонал”. ИТ-система - “набор информационно-технологических ресурсов, обеспечивающий услуги по одному или нескольким интерфейсам” (ГОСТ Р ИСО/МЭК ТО 10000-1-99 )


Слайд 128

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


Слайд 129

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


Слайд 130

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


Слайд 131

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


Слайд 132

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


Слайд 133

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


Слайд 134

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


Слайд 135

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


Слайд 136

Значительное число проектов в отечественной практике создания КИУС завершается неудачно либо имеет тенденцию неограниченного увеличения сроков внедрения при одновременном отсутствии значимых результатов. При этом объяснение причины неудачи является традиционным – “предприятие не готово к внедрению”. Риторические вопросы: Зачем на этом предприятии работали внедренцы-консультанты, ежедневная оплата услуг которых обходилась предприятию в круглую сумму? Почему, получив в итоге за сотни тысяч и миллионы долларов дырку от бублика, предприятия не пытаются вернуть свои деньги, в лучшем случае лишь прерывая контракт?


Слайд 137

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


Слайд 138

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


Слайд 139

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


Слайд 140

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


Слайд 141

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


Слайд 142

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


Слайд 143

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


Слайд 144

Основные этапы построения КИУС Определение целей проекта Подготовка к созданию КИУС Выбор поставщиков компонент КИУС Создание КИУС


Слайд 145

Определение целей проекта анализ опыта похожих предприятий по созданию КИУС определение целей проекта в контексте системы управления формирование критериев успешности проекта формирование финансового плана


Слайд 146

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


Слайд 147

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


Слайд 148

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


Слайд 149

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


Слайд 150

3. Анализ требований к КИУС и разработка ТЗ на систему Цели: достижение взаимопонимания между всеми участниками разработки относительно функций и характеристик КИУС; обеспечение возможности “видения” и корректировки будущей системы до того, как она будет реализована физически; уменьшение затрат на разработку и внедрение системы; обеспечение базиса для планирования, оценки стоимости и времени создания системы.


Слайд 151

def Системное проектирование (по другому, моделирование требований к будущей системе) является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются “Что должна делать будущая система?”


Слайд 152

Критичные этапы жизненного цикла КИУС Главная особенность индустрии КИУС - концентрация сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов Анализ требований - первая фаза разработки, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?" Этап проектирования - дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?"


Слайд 153

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


Слайд 154

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


Слайд 155

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


Слайд 156

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


Слайд 157

4. Выбор наиболее подходящих программных решений типовые (тиражируемые) компоненты предметные компоненты


Слайд 158

Типовые компоненты системы управления предприятиями (MRP-II - Manufactory Resource Planning / ERP – Enterprise Resource Planning) системы управления активами и фондами (EAM - Enterprise Asset Management) системы управления взаимоотношениями с клиентами (CRM – Customer Relations Management) системы управления цепочками поставок (SCM – Supply Chain Management) информационно-аналитические системы (ИАС) системы расчета зарплаты и учета кадров и др.


Слайд 159

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


Слайд 160

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


Слайд 161

Соображения по выбору ПО Обозначение границ реализации Выбор подходящих технических средств Анализ и выбор компонент тиражируемой системы Заказная разработка


Слайд 162

Обозначение границ реализации Основные типы реализации: ручная пакетная диалоговая реального времени


Слайд 163

Основные варианты выбора компонент КИУС заказная или тиражируемая отечественная или зарубежная весовая категория – от локальных до крупных интегрированных и/или их отдельных модулей.


Слайд 164

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


Слайд 165

Заказная или тиражируемая?


Слайд 166

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


Слайд 167

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


Слайд 168

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


Слайд 169

Отечественная ситуация Значительное число проектов в отечественной практике создания КИУС завершается неудачно либо имеет тенденцию неограниченного увеличения сроков внедрения при одновременном отсутствии значимых результатов. При этом объяснение причины неудачи является традиционным (и очень удобным для консультантов-внедренцев) – “предприятие не готово к внедрению”.


Слайд 170

Причины неудач (1) Фактически не система настраивается под предварительно реорганизованные бизнес-процессы конкретного предприятия, а наоборот, предприятие перестраивается под систему (любимая фраза внедренцев - “мы проводим реинжиниринг под нашу систему”). При этом зачастую и сам выбор системы осуществляется не на основании детальных функциональных требований к соответствующей компоненте КИУС, а попросту навязывается поставщиком. В одном из последних бюллетеней MIT Sloan Management Review отмечается – “от 30 до 75% систем не соответствуют ожиданиям пользователей, главная причина – стремление подогнать бизнес-процессы предприятия под существующую технологическую инфраструктуру”. “Для человека с молотком все выглядит как гвоздь”


Слайд 171

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


Слайд 172

Причины неудач (3) Фактически настройки осуществляются членами проектной группы самого предприятия (бухгалтерами, экономистами, плановиками и т.п.), прошедшими короткое обучение – консультанты лишь отвечают на их конкретные вопросы и решают вставшие перед ними проблемы.


×

HTML:





Ссылка: