7.Сущность и основные понятия инфю консалтинга.
Консалтинг - это деятельность специалиста или целой фирмы, занимающихся стратегическим планированием проекта, анализом и формализацией требований к информационной системе, созданием системного проекта, иногда - проектированием приложений. Но все это до этапа собственно программирования или настройки каких-то уже имеющихся комплексных систем управления предприятием, выбор которых и осуществляется на основе системного проекта. И уж ни в коей мере сюда не входит системная интеграция. Консалтинг предваряет и регламентирует названные этапы.
Фактически консультантом выполняется два вида работ. Прежде всего – это элементарное наведение порядка в организации: бизнес-анализ и реструктуризация (реинжиниринг бизнес-процессов). Это направление получило название “бизнес-консалтинг”. Деятельность, направленная на то, чтобы разобраться в функционировании организвации, построить соответствующие модели и на их основе выдвинуть некоторые предложения по поводу улучшения работы некоторых звеньев, а еще лучше - бизнес-процессов (деятельностей, имеющих ценность для клиента) считается бизнес-консалтингом.
Другой вид работ - собственно системный анализ и проектирование. Выявление и согласование требований заказчика приводит к пониманию того, что же в действительности необходимо сделать. За этим следует проектирование или выбор готовой системы так, чтобы она в итоге как можно в большей степени удовлетворяла требованиям заказчика.
Важный элемент консалтинга - формирование и обучение рабочих групп. Здесь речь идет не только о традиционной учебе, любые проекты, модели должны в итоге кем-то сопровождаться. Поэтому сотрудники предприятия с самого начала участвуют в проекте, им частично передаются внутрифирменные технологии. И по окончании работ они способны анализировать и улучшать бизнес-процессы в рамках собственной отдельно взятой организации.
Консалтинговые структуры характеризуются следующими четырьмя позициями: •знания и информация - главный и единственный их продукт; •опыт персонала, приобретаемый годами и десятилетиями при работе над конкретными проектами; •независимость; •объективность.
Основными целями разработки консалтинговых проектов являются: •представление деятельности предприятия и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения; •формирование на основании анализа предложений по реорганизации организационно-управленческой структуры; •упорядочивание информационных потоков (в том числе документооборота) внутри предприятия; •выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром; •анализ требований и проектирование спецификаций корпоративных информационных систем; •рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP - manufacturing resource planning и ERP - enterprise resource planning).
Этапы:
1. Анализ первичных требований и планирование работ. Основными задачами являются: анализ первичных бизнес-требований, предварительная экономическая оценка проекта, построение план-графика выполнения работ, создание и обучение совместной рабочей группы.
2. Проведение обследования деятельности предприятия. В рамках данного этапа осуществляется: •предварительное выявление требований, предъявляемых к будущей системе; •определение оргштатной и топологической структур предприятия; •определение перечня целевых задач (функций) предприятия; •анализ распределения функций по подразделениям и сотрудникам; •определение перечня применяемых на предприятии средств автоматизации.
По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели предприятия, включающей идентификацию внешних объектов и информационных взаимодействий с ними, а также детализацию до уровня основных деятельностей предприятия и информационных связей между этими деятельностями.
3. Построение моделей деятельности предприятия.
На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов: •модели “как есть”, представляющей собой "снимок" положения дел на предприятии на момент обследования. Позволят понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации; •модели “как должно быть”, интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.
Каждая из моделей включает в себя полную структурную функциональную модель деятельности, информационную модель, а также, в случае необходимости, событийную (описывающую поведение) модель (с использованием диаграмм переходов состояний)./p>
Переход от модели “как есть” к модели ”как должно быть” осуществляется следующими двумя способами. 1)Совершенствование технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников (“легкий” реинжиниринг). 2)Радикальное изменение технологий и переосмысление бизнес-процессов (“жесткий” реинжиниринг).
4. Разработка системного проекта
Данный этап является первой фазой разработки собственно системы автоматизации. На этом этапе определяются: •архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями; •интерфейсы и распределение функций между человеком и системой; •требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы; •состав людей и работ, имеющих отношение к системе; •ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Системный проект строится на основе модели “как должно быть” . По завершении данного этапа (после согласования системного проекта с заказчиком) изменяется роль консультанта. Отныне он как бы становится на сторону заказчика, и одной из его основных функций на всех последующих этапах работ будет являться контроль на соответствие требованиям, зафиксированным в системном проекте.
5. Разработка предложений по автоматизации предприятия
На основании системного проекта осуществляется: •составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними; •анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору такой системы; •совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы; •разработка требований к техническим средствам; •разработка требований к программным средствам; •разработка предложений по этапам и срокам автоматизации.
6. Разработка технического проекта
На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Этот этап разделяется на два подэтапа: •проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами; •детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей.
7. Последующие этапы
В случае разработки собственной системы последующие этапы являются традиционными: по спецификациям технического проекта осуществляется программирование модулей, их тестирование и отладка, и последующая комплексация в автоматизированные рабочие места и в систему в целом. При этом схема интегрированной базы данных, как правило, генерируется автоматически на основании информационной модели.
CASE-технологии - методологическая и инструментальная база консалтинга
За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering). Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.
Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования ПО. Чем больше деятельности будет вынесено в проектирование из кодирования, тем лучше.
При использовании CASE-технологий изменяются все этапы жизненного цикла программной системы, при этом наибольшие изменения касаются этапов анализа и проектирования. В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой системы используются графы, диаграммы, таблицы и схемы. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру с все большим числом уровней.
CASE обладают следующими основными достоинствами: •улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта); •позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат; •ускоряют процесс проектирования и разработки; •освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки; •поддерживают развитие и сопровождение разработки; •поддерживают технологии повторного использования компонент разработки.