Организационная структура – это распределение ответственности, полномочий и взаимоотношений между работниками предприятия.
Как правило, наилучшим способом отображения организационной структуры является организационная диаграмма в виде многоуровневого дерева (графа). Рекомендуется использовать инструментарий MS Visio. Также можно использовать пакет AllFusion Modelling Suite в части AllFusion Process Modeler 7.1 (BPwin), Organization Charts.
О системе управления следует говорить, если на предприятии существует управленческий программный комплекс класса ERP, MRPII или CRM. В определенной степени задачам управления служат финансовые системы. В данном разделе рекомендуется перечислить программные продукты с указанием структур, которые участвуют в эксплуатации.
Стратегия развития и бизнес-архитектура предприятия.
При описании стратегии рекомендуется использовать распространенные методики «послойного» анализа архитектур бизнеса и информационных технологий. Например, методологию Захмана:
Рис. . Модель архитектуры бизнеса Захмана (по Данилин, 2005)
Важно показать, как стратегия и бизнес-архитектура предприятия определяет стратегию и развития и оперативные задачи ИТ.
Рекомендуется максимально использовать документы стратегического характера, имеющиеся на фирме. Самостоятельная разработка моделей такого рода очень трудоемка и, как правило, может быть самостоятельной дипломного проекта и ВКР.
Состояние и стратегия развития информационных технологий (ИТ-архитектура).
При описании состояния ИТ на предприятии рекомендуется привести фактическую структуру корпоративной ИС или ее отдельных элементов, а также перечень используемых программных продуктов, технологий и т.д.
Если на предприятии имеется корпоративная информационная система управленческого класса (ERP, MRPII, CRM, например, SAP R/3 или 1С-Предприятие 8), то рекомендуется описать ее функциональность, особенности эксплуатации, проблемы, возникающие в связи с ее использованием.
Стратегия развития ИТ должна вытекать из бизнес-архитектуры. Как правило, на малых и средних предприятиях целостная ИТ-стратегия отсутствует. В этом случае, рекомендуется такую стратегию разработать и рассматривать как в качестве важного результата ВКР.
Функциональная модель и (или) процессная модель организации «AS-IS».
Процессная модель предприятия служит системной и алгоритмической основой для любых действий по автоматизации. Информационные системы всегда служат информационно-коммуникационным обеспечением конкретных процессов, а не «организации вообще». Таким образом, правильное описание и анализ системы основных и вспомогательных процессов является необходимым условием эффективного внедрения ИС.
Следует различать функциональный и процессный подходы в управлении. В явном виде процессный подход практикуется далеко не во всех предприятиях. В этом случае, вклад автора ВКР в создание процессной системы управления может стать очень существенным компонентом дипломного проекта. Описание ситуации и рекомендации по оптимизации следует дать максимально полно, с использованием любых средств моделирования и визуализации результатов.
При анализе ситуации рекомендуется опираться на стандарты управления качеством (TQM, Total Quality Management). Оптимальными являются нотации SADT (IDEF0), SwimLane, IDEF3, диаграммы групп UML, ARIS, BPMN (Бабенко, 2010). Желательно при описании функциональности использовать объектный подход – нотации диаграммы классов и объектов (UML), а также составить детальную понятийную модель (тезаурус, онтологию).
Модель потоков данных (информационные потоки, обеспечивающие бизнес-процессы и бизнес-функции организации «AS-IS»).
Информационные системы отражают деятельность предприятия в терминах потоков информации: управленческих документов, данных, обеспечивающих принятие оперативных решений, аналитических информационных выборок, необходимых для стратегического анализа. Поэтому, модель информационных потоков – это основа для информатизации любого рода.
Рекомендуется использовать нотации DFD, ERD, диаграммы классов UML. Важнейшие первичные документы (шаблоны или образцы) желательно привести в приложениях. Особенно важно описать в формате as-is структуру существующих баз данных.
Оценка уровня зрелости организации и процессов ее управления.
Рекомендуется определить уровни зрелости информационных систем на объекте в соответствие с моделью CMM (Capability Maturity Model) и с учетом технологии COBIT (Control Objectives for Information and related Technology).
При оценки зрелости организации в качестве шаблона рекомендуется использование модель Адезиса:
Рис. Модель жизненного цикла предприятия (по Адезис, 2007)
Определение точки, соответствующей уровню развития конкретной организации крайне важно для реинжиниринга и проектирования ИТ-архитектуры, поскольку каждая фаза характеризуется определенной адаптивностью к информационным технологиям. По признакам, описанным в (Адезис, 2007) рекомендуется провести такой анализ с максимально возможной точностью.
Возможны и альтернативные классификации. Например, многоуровневая классификация:
Уровень 1 —начальный («анархия»).
На этом уровне получается искаженная картина рентабельности бизнеса, иллюзорное чувство бурной деятельности при весьма скромных результатах. Приоритет здесь отдается дешевизне программных средств и простоте их использования. Производится оценка единовременных затрат на закупку и внедрение программно-аппаратных комплексов и выбирается вариант, где они наименьшие.
Уровень 2 — повторяемый («фольклор»).
Более устойчивый характер бизнеса, повторяемость основных бизнес-процессов и возможность реального управления ими заставляют обратить пристальное внимание на вопросы учета. Контроль за движением материальных и денежных средств, поиск путей снижения издержек — эти задачи приобретают актуальное звучание. Приоритеты смещаются в сторону формирования оперативных планов, разработка которых ведется с учетом полученного опыта и знаний.
При выборе ИТ–решения оцениваются единовременные затраты на закупку программно-аппаратных комплексов и их внедрение с учетом прошлого опыта.
Уровень 3 — определенный («стандарты»).
Акценты постепенно смещаются из области учетной политики в область аналитики, осознается и начинает развиваться управление корпоративными знаниями. Тем не менее, в рамках оперативного планирования постановка долгосрочных целей фактически не производится и базируется в основном на показателях предшествующего периода. Планка требований и уровень задач, решения которых ждут от ИТ-проекта, повышаются. Предприятия, находящиеся на этом уровне развития, как правило, обладают развитой инфраструктурой: сеть филиалов и удаленных складов, многочисленный штат менеджеров, структурное деление на отделы и подразделения.
Для оперативного управления значительным потоком информации в режиме реального времени система должна позволять делать "моментальный снимок" состояния компании.
Для выбора информационных технологий уже не просто оценивают, а производят глубокий анализ единовременных затрат на закупку и внедрение программно-аппаратных комплексов.
Уровень 4 — управляемый (измеряемый).
На этом этапе формируются внутрифирменные стандарты контроля и количественного измерения качества не столько самой продукции, сколько всех процессов — от производства до сбыта. Новые стандарты распространяются не только на внутренние бизнес-процессы, но и на внешнее окружение. Здесь уже компаниям важно, чтобы их контрагенты, поставляющие необходимую продукцию, комплектующие и услуги, также были в состоянии обеспечить требуемый уровень качества. Наличие своих постоянных и надежных клиентов составляет базу для долгосрочного планирования. Плановые решения принимаются не интуитивно, а на основе явных знаний, которыми обладает компания. Стратегические и оперативные планы взаимосвязаны, обратная связь обеспечивает эффективное согласование между этими уровнями управления.
Уровень 5 — оптимизируемый.
Это высший уровень, которого могут достичь компании-лидеры, способные на основе количественных критериев управлять качеством по всей цепочке, включая поставки, производство, сбыт, дальнейшее обслуживание, и с учетом этого оптимизировать все свои процессы. Дальнейшая их стратегия направлена на достижение и сохранение технологического, организационного и финансового преимущества. Формализация бизнес-процессов и рыночных перспектив позволяет не только просчитать стратегические планы, но и оптимизировать пути их достижения.
Проблемный анализ ключевых бизнес-процессов (анализ «узких мест») с точки зрения бизнес-целей организации.
«Узкие» места рекомендуется определять на основе анализа построенных функциональных моделей и моделей потоков данных на соответствие эталонной модели (использовать библиотеку лучших практик ITIL). При этом анализ рекомендуется проводить по следующим направлениям:
анализ функциональной деятельности выбранной предметной области на соответствие лучшей бизнес-практике или эталонной модели (стандарты и модели MRP, ERP, CRM…);
анализ функционального взаимодействия выбранной предметной области с внешними объектами на соответствие лучшей бизнес-практике или эталонной модели;
анализ внутреннего документооборота выбранной предметной на соответствие лучшей бизнес-практике или эталонной модели;
анализ информационных потоков и информационного взаимодействия с внешними объектами на соответствие лучшей бизнес-практике или эталонной модели;
анализ информационной инфраструктуры выбранной предметной области и предприятия в целом на соответствие лучшей бизнес-практике или эталонной модели;
анализ информационной обеспеченности бизнес-процессов и эффективности хранилищ данных корпоративного масштаба.
Информация для моделирования должна быть получена по методикам «выявления требований». При этом используются информационные источники:
Техническая и бизнес-документация.
Интервьюирование и анкетирование экспертов и ключевых специалистов.
Наблюдение функционирования бизнес-процессов.
По результатам проблемного анализа определяются конкретные цели оптимизации (реинжиниринга). Рекомендуется построение целевых (to-be) моделей улучшенных процессов в любых нотациях (IDEF, UML, ARIS, BPMN).
1.2. Анализ лучших практик в предметной области и обоснование выбора решения по оптимизации или реинжинирингу
Изучение специфики предметной области по литературным данным и по результатам поиска в интернете.
Данный подраздел особенно важен для ВКР, которые носят инновационный или исследовательский характер.
В подразделе суммируется имеющаяся информация по решению задач, аналогичных поставленным, другими исследователями и на других объектах, а также, при необходимости, проводится компилятивный теоретический анализ. Методологически рекомендуется базироваться на бенчмаркинговой библиотеке ITIL (Information Technologies Infrastructure Library).
Обоснование решения по направлению и технологии оптимизации бизнес-процессов.
На основе построенных целевых моделей бизнес-процессов и выявленных лучших практик определяется конфигурация проекта, ориентированного на решение задач и достижение целей. Рекомендуется в данном подразделе кратко прокомментировать основные разделы технического задания.
Глава 2. Концептуальное обоснование проекта
2.1 Классы и характеристики пользователей
Для любого ИТ-проекта определяющим фактором являются особенности заказчика, потенциальных пользователей и заинтересованных лиц (stakeholders).
В качестве заказчика, как правило, выступают топ-менеджеры предприятия. Они формулируют общие требования к результатам проекта, осуществляют согласование. Рекомендуется четко определить заказчика, его юридический или иерархический статус и вклад в формулирование требований.
Понятие «пользователь» не совпадает с понятием «заказчик». Пользователям предстоит эксплуатировать разработанную или внедренную систему. Рекомендуется расклассифицировать пользователей на категории (например, операторы и администраторы), и в дальнейшем указывать требования соответствующего класса при определении бизнес-логики.
Заинтересованные лица проекта (stakeholders) – это, например, юридические и физические лица, финансирующие проект, предоставляющие временные трудовые ресурсы. В рамках ВКР достаточно их перечислить с указанием конкретных степеней заинтересованности.
2.2. Описание функциональных требований проекта
Описание методологии и техник выявления требований.
Рекомендуется охарактеризовать методики выявления и спецификации требований в рамках дипломного проектирования. Как правило, используются:
различного рода анкетирования специалистов (желательно привести в приложениях разработанные анкеты), подразумевающие статистическую или неформальную обработку результатов;
круглые столы и мозговые штурмы (привести протоколы проведения мероприятий);
интервьюирования специалистов;
согласования промежуточных моделей и сценариев.
Практически всегда используется большое количество нотаций для представления результатов as-is: группа диаграмм IDEF, различные виды диаграмм UML, бизнес-моделирование BPMN и др. Желательно кратко обосновать выбор тех или иных средств.
Описание бизнес-логики и функциональных требований.
Постановка задачи на разработку информационного продукта или на адаптацию и внедрение существующего многотиражной системы обязательно подразумевает максимально полное и однозначное описание функциональных требований. Рекомендуется разбить их на блоки по важности: абсолютно необходимая функциональность, желательная функциональность, возможная функциональность и исключенные из рассмотрения функции (модель MoSCoW – Mast Have, Should Have, Could Have и Would’t Have). Обобщенно такой набор требований считается бизнес-логикой проектируемой системы.
Наиболее важные направления бизнес-логики:
Сценарные модели и схемы взаимодействия с разрабатываемой системой бизнес-пользователей.
Требования прикладных интерфейсов и экранных форм (включая макеты, стандарты шрифтов, значков и цветовых характеристик, ограничения разрешения экрана, быстрые клавиши, специальные возможности для пользователей с проблемами со зрением).
Требования к хранилищам данных и серверной логике (максимально полное описание баз данных в ERD-формате, требования к целостности данных, распределение функциональности между «клиентом» и «сервером», необходимость и спецификация организации витрин данных (Data Marts) и т.д.).
Шаблоны выходных документов и отчетных форм (рекомендуется описать и привести в приложениях все основные отчетные документы, которые создает программа).
Форматы и интерфейсы обмена данными между программами и в сетевой среде (основные протоколы, необходимость подключения стандартных программ, OLE-механизмы, необходимость XML-формата и т.д.).
Требования к защите данных и контролю доступа (степень важности и уязвимости данных, особенности разграничения доступа к информации, необходимость шифрования, необходимость и особенности авторизации при входе в систему и т.д.).