Всё для Учёбы — студенческий файлообменник
1 монета
ppt

Студенческий документ № 050923 из МЭСИ

Методология ИТ-консалтинга

Калянов Георгий Николаевич

профессор, доктор технических наук

зав. кафедрой "Системный анализ и управление ИТ"

зав. лабораторией Института проблем управления РАН

Kalyanov@mail.ru

http://www.kalyanov.by.ru

Тема 4. Системный слой предприятия

Система (на современном этапе)

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

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

Информационная система

• ИС - система, предназначенная "для сбора, передачи, обработки, хранения и выдачи информации потребителям и состоящая из следующих основных компонентов:

* программное обеспечение;

* информационное обеспечение;

* технические средства;

* обслуживающий персонал".

• ИТ-система - "набор информационно-технологических ресурсов, обеспечивающий услуги по одному или нескольким интерфейсам" (ГОСТ Р ИСО/МЭК ТО 10000-1-99 )

Экономические предпосылки создания и использования КИУС

• обеспечение гибкости рыночно-продуктовой стратегии

• эффективное взаимодействие с партнерами

• эффективная работа с клиентами

• эффективное управление ресурсами и процессами

• оперативное получение достоверной информации

• анализ больших информационных объемов

Руководителей предприятий интересует:

• агрегация данных (а не обилие конкретных значений)

• динамика, перспективы, тенденции (а не статика)

• корпоративные решения (а не решения для подразделений)

• минимальные затраты на поиск требуемой информации

• полнота и непротиворечивость информации

• аналитические срезы для поддержки принятия решений.

Требования со стороны руководителей

• решение всего комплекса задач бизнеса

• сбалансированная стоимость владения

• широкие функциональные возможности

• быстродействие и гибкость

• безопасность.

Требования, обеспечиваемые современным уровнем развития ИТ

• функциональная полнота;

• масштабируемость - система должна учитывать растущие потребности предприятия;

• гибкость - система должна настраиваться на изменения бизнес-процессов и внешней среды;

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

• информационная безопасность;

• экономическая эффективность;

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

Уже не стоит вопрос "надо или не надо создавать КИУС", предприятия столкнулись с проблемой: каким образом это осуществить?

Это обусловлено:

> повышением степени организационной и финансовой самостоятельности;

> выходом на зарубежный рынок;

> стремлением ряда западных компаний производить свои товары в России;

> завершением периода "островковой" автоматизации;

> возрастающей ориентацией предприятий на бизнес-процессы, т.е. деятельности, имеющие ценность для клиента;

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

Цели создания КИУС

• автоматизация ручного труда

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

Не существует двух одинаковых предприятий

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

==> возникает проблема выбора именно той системы, которая наиболее подходит для конкретного предприятия ==>

==> сложность проблемы обуславливается:

* масштабностью тиражируемых систем управления предприятиями

* тонкими отличиями реализации технологий основных бизнес-процессов

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

Ошибочный подход №1

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

Ошибочный подход №2

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

Схема создания КИУС

Виды моделей

* Модели бизнес-процессов

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

* "AS TO BE" - интеграция перспективных предложений руководства и сотрудников предприятия, экспертов и системных аналитиков по совершенствованию бизнес-процессов предприятия

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

* Технический проект, являющийся заданием для осуществления настроек/программирования

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

Фредерик Брукс

Моделирование

* Моделирование БП. Процесс должен быть описан в первую очередь с использованием средств функционального моделирования. Функциональная модель процесса является основой проведения работ по его реинжинирингу, ценным средством для размышлений и совместной работы над перспективами развития предприятия и системной разработкой, поскольку руководство прекрасно ориентируется в технологиях предприятия, и модели данного типа интуитивно понимаемы неспециалистами.

* Формализация, документирование и согласование требований к КИУС на основе разработанных моделей БП. Требования к КИУС должны быть промоделированы с использованием средств как функционального, так и информационного моделирования.

Анализ

* формирование предложений по автоматизации

* планирование объемов и сроков внедрения компонентов КИУС

* определение последовательности работ и необходимых для их выполнения ресурсов

Предложения по автоматизации предваряют анализ рынка тиражируемых решений и выбор системы, наиболее полно удовлетворяющей предъявленным требованиям.

Создание КИУС не означает полного отказа от всех существующих на предприятии ПС, условно разделяемых на следующие категории:

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

* ПС уровня административно-хозяйственного управления предприятиям, которые в свою очередь могут быть разделены на:

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

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

Проектирование

Технический проект КИУС должен содержать технические решения в трех направлениях работ:

* по настройкам тиражируемой системы

* по интеграции тиражируемой системы и существующих на предприятии ПС

* по автоматизации специфических процессов предприятия путем разработки собственного ПО или конфигурирования выбранного стандартного ПО.

Реализация

* разработка собственного ПО и интерфейсов к существующим ПС

* настройка тиражируемой системы

* интеграция компонентов

Тестирование и опытная эксплуатация прототипа

* ввод данных в систему

* отладка и тестирование рабочих мест, отчетов и выходных форм

* разработка инструкций и обучение конечных пользователей

На данном этапе могут быть выявлены дополнительные требования к КИУС, реализация которых отсутствует в техническом проекте. В этом случае осуществляется его доработка.

Продуктивная эксплуатация

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

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

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

Риторические вопросы:

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

• Почему, получив в итоге за сотни тысяч и миллионы долларов дырку от бублика, предприятия не пытаются вернуть свои деньги, в лучшем случае лишь прерывая контракт?

Приоритетность предприятия над ИТ

• аудит соответствия уже имеющихся на предприятии информационных систем целям и задачам бизнеса;

• разработка концепции создания КИУС;

• выявление, формирование и анализ требований к КИУС;

• выбор компонент КИУС, наиболее полно удовлетворяющих этим требованиям.

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

• общая характеристика объекта аудита

• техническая оценка по каждой из анализируемых систем

Общая характеристика объекта аудита

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

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

• состояние и состав эксплуатируемого системного программного обеспечения;

• состояние и состав аппаратного обеспечения;

• обеспечение информационной безопасности эксплуатируемых систем.

Техническая оценка каждой из систем

• состав подсистем и перечень функций системы;

• схемы информационных взаимодействий с другими системами;

• степень покрытия бизнес-процессов предприятия функциональностью системы;

• направления и приоритетность развития функциональности системы;

• оценка методологии создания системы;

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

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

• общая оценка системы и выводы о ее возможном использовании при построении КИУС.

2. Разработка концепции КИУС

Состав концепции:

• описание основных требований к системе со стороны функциональных подразделений;

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

• описание существующих проблем, связанных с эксплуатацией приложений и аппаратных средств;

• описание предлагаемых решений с их обоснованием;

• план развития системы на 2-3 года.

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

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

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

Основные положения

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

• внедряются не просто системы, а комплекс технологий учета и управления, подкрепленный соответствующими программными и техническими инструментами;

• состав этого комплекса определяется актуальными потребностями предприятия и его реальными возможностями.

Принципы

1) Функциональность. Реализация принципа функциональности подразумевает непрерывное соответствие КИУС потребностям предприятия на протяжении жизненного цикла системы и обеспечивает возможность ее расширения и модернизации.

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

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

Принципы

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

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

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

Базовые концепции

• информационная безопасность

• управление проектами

• документационное обеспечение

• управление качеством.

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

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

• Начало эксплуатации системы (функциональных подсистем) может быть обеспечено в сжатые сроки, особенно при исполнении пилотных проектов, реализующих базовую функциональность.

• Развитие системы и расширение функциональности идет путем подключения и ввода в эксплуатацию новых модулей.

• Сокращаются единовременные затраты на создание КИУС, т.к. бюджет может быть распределен во времени.

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

Основные этапы построения КИУС

• Определение целей проекта

• Подготовка к созданию КИУС

• Выбор поставщиков компонент КИУС

• Создание КИУС

Определение целей проекта

• анализ опыта похожих предприятий по созданию КИУС

• определение целей проекта в контексте системы управления

• формирование критериев успешности проекта

• формирование финансового плана

Подготовка к созданию КИУС

• организация тендера, выбор генерального подрядчика и поставщика консалтинговых услуг

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

• формирование плана-графика проведения работ на этапе

• анализ, выбор и утверждение проектных методологий и методик по этапу

• формирование и обучение рабочей группы аналитиков

• проведение обследования предприятия

• моделирование "как есть" и "как должно быть" и, по необходимости, реорганизация бизнес-процессов

• утверждение бизнес-модели "как должно быть"

• уточнение целей и критериев успешности проекта создания КИУС

• разработка требований к КИУС (системного проекта)

• разработка технических заданий (общего и частных по каждой из компонент)

• анализ рынка и выработка предложений по компонентам КИУС (включая и собственную разработку)

Реорганизация

Создание КИУС никогда не принесет предприятию должного эффекта без проведения комплекса работ по реорганизации его бизнес-процессов.

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

Реорганизация

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

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

Таким образом, реорганизация БП должна быть в основном выполнена на этапе моделирования БП и завершена на этапе проектирования ИИСУП.

Выбор поставщиков компонент КИУС

• формирование требований к поставщику

• организация презентаций поставщиков

• выбор поставщиков

• определение форм сотрудничества и заключение контрактов с поставщиками

Создание КИУС

• разработка и утверждение плана-графика создания

• формирование и обучение рабочей группы

• разработка технического проекта

• настройка и тестирование тиражируемых компонент

• разработка уникальных компонент

• интеграция компонент в опытную версию КИУС

• опытная эксплуатация КИУС

• разработка методик работы с КИУС

• обучение и сертификация пользователей и администраторов

• переход к промышленной эксплуатации КИУС

3. Анализ требований к КИУС и разработка ТЗ на систему

Цели:

• достижение взаимопонимания между всеми участниками разработки относительно функций и характеристик КИУС;

• обеспечение возможности "видения" и корректировки будущей системы до того, как она будет реализована физически;

• уменьшение затрат на разработку и внедрение системы;

• обеспечение базиса для планирования, оценки стоимости и времени создания системы.

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

"Что должна делать будущая система?"

Критичные этапы жизненного цикла КИУС

* Главная особенность индустрии КИУС - концентрация сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов

* Анализ требований - первая фаза разработки, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?"

* Этап проектирования - дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?"

Проблемы при формировании требований

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

• требования от различных заинтересованных лиц могут быть противоречивыми;

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

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

• число требований может быть огромным (и разной степени детализации) и вследствие этого неуправляемым;

• требования изменяются и т.д.

Системный проект

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

* интерфейсы и распределение функций между человеком и системой;

* требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;

* состав людей и работ, имеющих отношение к системе;

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

В рамках системного проектирования должно быть осуществлено:

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

* определение состава и структуры программных средств автоматизации технологии решения задач с учетом существующих средств в структурных подразделениях;

* определение структуры и характеристик информационного обеспечения технологии решения задач;

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

* разработка состава автоматизируемых процедур документооборота

Системный проект должен включать:

• полную функциональную модель требований к будущей системе;

• комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);

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

• концептуальную модель интегрированной базы данных (пакет диаграмм);

• архитектуру системы с привязкой к концептуальной модели;

• предложения по оргштатной структуре для поддержки системы

Преимущества по сравнению с традиционной разработкой

Системный проект позволяет:

* описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически

* уменьшить затраты на разработку и внедрение системы

* оценить разработку по времени и результатам

* достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.)

* улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру интегрированной БД, выполнить функциональную декомпозицию типовых модулей

Другие достоинства системного проекта

* включает в себя модель существующей технологии, работающей на предприятии

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

* позволяет осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности

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

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

Главная особенность структурирования

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

Три правила накопителей

• Данные должны заносится в накопитель один раз в том месте, где они впервые появляются.

• Если данные из некоторого накопителя используются по крайней мере двумя процессами, то этот накопитель должен присутствовать на содержащей эти процессы диаграмме.

• На втором уровне модели должны быть введены базовые накопители

Второй уровень системного проекта

Базовые накопители

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

2. Технологический транспорт - используется для хранения данных по автосамосвалам: учетной карточки, данных по проведенным ТО, истории автосамосвала.

3. Перевозки - используется для хранения данных по перевозкам на основе диспетчерской сводки.

4. Ремонты - используется для хранения данных о любом ремонте, включая перечень замененных узлов и агрегатов.

5. Запасные части и материалы - используется для хранения данных о имеющихся в наличии запчастях и материалах, включая данные по складу запчастей, складу материалов, инструментальному складу и оборотному складу.

ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы

• общие сведения

• назначение и цели создания системы

• характеристика объекта автоматизации

• требования к системе

• состав и содержание работ по созданию системы

• порядок контроля и приемки системы

• требования по подготовке и вводу в действие

• требования к документированию

• источники разработки

• глоссарий

4. Выбор наиболее подходящих программных решений

• типовые (тиражируемые) компоненты

• предметные компоненты

Типовые компоненты

• системы управления предприятиями (MRP-II - Manufactory Resource Planning / ERP - Enterprise Resource Planning)

• системы управления активами и фондами (EAM - Enterprise Asset Management)

• системы управления взаимоотношениями с клиентами (CRM - Customer Relations Management)

• системы управления цепочками поставок (SCM - Supply Chain Management)

• информационно-аналитические системы (ИАС)

• системы расчета зарплаты и учета кадров и др.

Примеры предметных компонент

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

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

Предложения по автоматизации

* составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

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

* совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

* разработка требований к техническим средствам;

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

* разработка предложений по этапам и срокам автоматизации.

Соображения по выбору ПО

• Обозначение границ реализации

• Выбор подходящих технических средств

• Анализ и выбор компонент тиражируемой системы

• Заказная разработка

Обозначение границ реализации

Основные типы реализации:

• ручная

• пакетная

• диалоговая

• реального времени

Основные варианты выбора компонент КИУС

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

• отечественная или зарубежная

• весовая категория - от локальных до крупных интегрированных и/или их отдельных модулей.

Недостатки заказной разработки

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

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

• тиражируемая система внедряется поэтапно и частично может быть доступна в рабочем режиме гораздо быстрее, чем заказная.

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

Проблема выбора

• масштабность тиражируемых систем;

• тонкие отличия реализации технологий основных бизнес-процессов;

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

Критерии выбора

• поддержка большинства функций, выявленных при анализе требований;

• поддержка концептуальной модели данных (информационной модели предприятия);

• наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;

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

• сложность сопровождения и администрирования;

• локализация, адаптация к российским условиям;

• деловые критерии продавца (прежде всего, его опыт внедрения и надежность).

Отечественная или зарубежная?

• Зарубежные системы ориентированы на хорошо структурированную иерархическую систему бизнес-процессов предприятия.

• Зарубежные системы, как правило, опираются на наборы стандартов, которым процессы должны удовлетворять.

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

• Российские системы более полно учитывают национальные особенности, российскую учетную специфику.

• Логика российских систем близка российским управленцам.

• Российские системы более удобны в случае работы с неполными, недостоверными или конфиденциальными данными.

Техническое проектирование - "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?"

2 этапа проектирования

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

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

Технический проект является расширением системного проекта

• за счет его уточнения;

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

• за счет построения моделей межмодульных и внутримодульных взаимодействий с использованием техники структурных карт

АРМ Диагностика: ER-модель

АРМ Диагностика: ER-модель

1) ДЕФЕКТОСКОПИЯ - результаты дефектоскопии автосамосвала

ДАТА ИСПЫТАНИЙ - дата проведения дефектоскопии

ТИП ДИАГНОСТИКИ - тип проводимых испытаний

НОМЕР ШАССИ - номер шасси проверяемого автосамосвала

2) ДИАГНОСТИКА ДИЗЕЛЯ - результаты диагностики дизеля

ДАТА ИСПЫТАНИЙ- дата проведения диагностики

ТИП ДИАГНОСТИКИ - тип проводимых испытаний

НОМЕР ШАССИ - номер шасси проверяемого автосамосвала

ДАВЛЕНИЕ МАСЛА - давление масла в системе

ДАВЛЕНИЕ ТУРБОНАДДУВА ЛЕВ - давление турбонаддува левого

ДАВЛЕНИЕ ТУРБОНАДДУВА ПРАВ- давление турбонаддува правого

ДАВЛЕНИЕ В ТОПЛ МАГИСТ - давление в топливной магистрали

МОЩНОСТЬ ДИЗЕЛЯ - мощность двигателя в л/с

Взаимосвязи информационной и функциональной моделей

АРМ Диагностика: функциональная модель

АРМ Диагностика: функциональная модель

Учет выполненной диагностики по дизелю

1) Занесение в таблицу ДИАГНОСТИКА следующей информации:

- дата испытаний

- номер шасси

- тип диагностики (дизель)

- табельный номер сотрудника

2) Занесение в таблицу ДИАГНОСТИКА ДИЗЕЛЯ следующей информации:

- давление масла в магистрали смазки

- давление турбонаддува (левого и правого)

- давление в топливной магистрали между топливным насосом и форсунками

- мощность дизеля

Отечественная ситуация

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

• При этом объяснение причины неудачи является традиционным (и очень удобным для консультантов-внедренцев) - "предприятие не готово к внедрению".

Причины неудач (1)

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

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

• В одном из последних бюллетеней MIT Sloan Management Review отмечается - "от 30 до 75% систем не соответствуют ожиданиям пользователей, главная причина - стремление подогнать бизнес-процессы предприятия под существующую технологическую инфраструктуру".

"Для человека с молотком все выглядит как гвоздь"

Причины неудач (2)

Детальное моделирование и анализ требований не производится по следующим причинам:

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

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

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

Причины неудач (3)

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

Вывод "Что немцу хорошо,

то русскому - смерть"

Система стандартов предприятия в ИТ-области

В современных условиях ИТ позиционируются как неотъемлемая функциональная часть бизнеса, ИТ являются критически важным ресурсом, который призван обеспечить конкурентное преимущество на рынке

Ключевые факторы, определяющие развитие ИТ современного предприятия:

• требования бизнес-блоков;

• требования по централизации управления ИТ;

• тенденции развития ИТ;

• внешние факторы (цены на продукцию, активности конкурентов, требования законодательства).

Основные проблемы, отечественных предприятий в области ИТ:

• отсутствие единой системы управления инвестиционными портфелями, программами работ и ИТ-проектами;

• отсутствие или неполнота архитектуры предприятия;

• наличие множества локальных унаследованных решений и излишних затрат на их поддержку;

• недостаточное внимание вопросам обеспечения эффективности ИТ:

• отсутствие сводного актуального ИТ-бюджета;

• недостаточная координация между различными ИТ-структурами и др.

Основные принципы перспективной модели ИТ-деятельности

• единый контролируемый бюджет ИТ, централизованное управление основными ресурсами, унифицированный механизм принятия решений в области ИТ;

• стандартизованные системы/технические решения для всех бизнес-блоков со схожими функциями;

• проектная направленность ИТ-деятельности;

• концентрация ответственности и необходимых прав в части принятия решений в рамках централизованной ИТ-службы;

• применение лучших мировых практик и стандартов в области построения ИТ-систем и организации процессов управления ими

Ключевые элементы перспективной модели ИТ-деятельности:

• измеримая услуга

• проект

• процесс ИТ-деятельности

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

• поддержка и эксплуатация инфраструктуры автоматизации, информационной безопасности, приложений (потребители - бизнес-блоки предприятия);

• поддержка бизнес-проектов (реализация ИТ-компонент проекта, рекомендации по выбору тех или иных технологических компонент и решений) (потребители - бизнес-блоки предприятия);

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

Бизнес-цель - программа - проект

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

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

Процессы деятельности при заказе, создании, приемке, вводе в действие и обслуживании ИТ

• формирование инвестиционного портфеля ИТ;

• программно-целевое планирование и бюджетирование работ по ИТ;

• заказ услуг по ИТ;

• организация и управление выполнением заказанных программ работ и проектов;

• приемка результатов программ работ и проектов;

• организация внедрения результатов.

Процессы деятельности при заказе, создании, приемке, вводе в действие и обслуживании ИТ

Процесс формирования инвестиционного портфеля ИТ

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

• декомпозиция цели каждой из программ работ в цели конкретных проектов;

• формирование портфеля проектов и программ работ.

Процесс программно-целевого планирования и бюджетирования работ по ИТ

• формирование бизнес-планов программ работ и проектов;

• формирование бюджетов программ работ и проектов;

• организация системы тендеров и выбор Подрядчиков;

• заключение договоров на оказание услуг/выполнение работ с Подрядчиками.

Процесс заказа услуг по ИТ

• сбор и анализ заявок на выполнение работ;

• согласование/отклонение заявки в случае несоответствия общей смете/бюджету проекта;

• формирование и согласование сметы и технического задания;

• присваивание номера заявке;

• передача заявки на исполнение.

Процесс организации и управления выполнением программ работ и проектов

• формирование организационной структуры управления программой работ/проектом;

• контроль и анализ хода выполнения программы работ/проекта;

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

Процесс приемки результатов

• формирование комиссии по приемке результатов программ работ и проектов;

• приемка результатов;

• формирование сводной отчетности по выполнению программы работ/проекта;

• уточнение параметров на следующий планируемый период.

Процесс организации внедрения результатов

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

• заключение сервисного соглашения с Подрядчиком;

• передача функциональному заказчику;

• организация развертывания необходимой ИТ-инфраструктуры у функционального заказчика по месту внедрения;

• организация проекта внедрения результатов по месту внедрения.

Соответствие уровней управления ИТ и областей стандартизации

Стандарты общего назначения

• ИТ. Термины и определения (на базе ГОСТ Р ИСО/МЭК 15288, ГОСТ Р ИСО/МЭК 12207);

• Порядок использования обозначений элементов ИТ;

• Положение о порядке ввода в действие международных стандартов, национальных стандартов РФ и корпоративных стандартов на предприятии;

• Правила проведения нормоконтроля при разработке и обновлении стандартов предприятия;

• Правила применения стандартов различных уровней (от международных до корпоративных стандартов) на предприятии;

• Правила организации и проведения контроля за соблюдением требований и правил, установленных в стандартах и других нормативных документах предприятия.

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

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

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

• стандарты и нормативные документы, непосредственно относящиеся к результату, вырабатываемому процессом моделирования.

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

• Основные положения по моделированию бизнес-процессов;

• Каталог бизнес-процессов;

• Регламент и методическое обеспечение деятельности по моделированию бизнес-процессов;

• Требования к составу, структуре и содержанию моделей, к языкам и инструментам моделирования, к контролю качества результатов моделирования, к составу, структуре и содержанию пакета отчетов и документов по результатам моделирования;

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

Стандарты в области информационных и автоматизированных систем

• ГОСТ 34.003-90 Информационная технология. Автоматизированные системы. Термины и определения.

• ГОСТ Р 34.201-89 Информационная технология. Виды, комплектность и обозначение документов при создании автоматизированных систем.

• ГОСТ Р 34.601-90.Информационная технология. Автоматизированные системы. Стадии создания

• ГОСТ Р 34.602-90. Информационная технология. Техническое задание на создание автоматизированной системы.

• ГОСТ 34.603-1992 Информационная технология. Виды испытаний автоматизированных систем

• ГОСТ 15.101-98. Порядок выполнения научно-исследовательских работ

• ГОСТ 7.32-2001. Отчет о научно-исследовательской работе. Структура и правила оформления

• ГОСТ Р ИСО/МЭК 12207. Информационные технологии. Процессы жизненного цикла программных средств;

• ГОСТ Р ИСО/МЭК ТО 15271-2002 Руководство по применению ГОСТ Р ИСО/МЭК 12207;

• ГОСТ Р ИСО/МЭК ТО 16326-2002 Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом;

• ГОСТ Р ИСО/МЭК 14764-2002. Информационные технологии. Сопровождение программных средств;

• ISO/IEC 2382-20:1990 Information technology -- Vocabulary -- Part 20: System development

• ISO/IEC 15288-2002. System engineering - System life cycle processes.

• ISO/IEC TR 19760:2003 Systems engineering -- A guide for the application of ISO/IEC 15288 System life cycle processes

• ISO/IEC TR 15846:1998 Information technology Software life cycle processes - Configuration management

• ISO/IEC TR 14759:2004. Software engineering - Mock up prototype - Categorization of software mock up and prototype models and their use

• ISO/IEC 18019:2004 Software and system engineering -- Guidelines for the design and preparation of user documentation for application software

• ISO/IEC 6592:2000 Information technology -- Guidelines for the documentation of computer-based application systems

• ISO/IEC 15910 Information technology - Software user documentation process.

В части общих требований к ИС/АС

• Глоссарий терминов по программной и системой инженерии;

• Классификатор информационных и автоматизированных систем.

В части жизненного цикла ИС/АС

• Процессы жизненного цикла ИС/АС;

• Технико-экономическое обоснование проекта ИС/АС, включая методики оценки ресурсоемкости и рисков;

• Документирование требований к ИС/АС;

• Требования к документированию ИС/АС и ПС;

• Порядок приемки ИС/АС;

• Положение об эксплуатации и сопровождении ИС/АС;

• Порядок утилизации ИС/АС.

В части жизненного цикла программных средств

• Процессы жизненного цикла ПС;

• Порядок разработки ПС;

• Документирование требований к ПС;

• Порядок проведения испытаний ПС;

• Порядок сопровождения ПС.

Стандарты в области ИТ-услуг (на базе стандартов COBIT и концептуальных документов ITIL/ITSM )

• Каталог услуг в области ИТ;

• Требования к описанию услуги;

• Соглашение об уровне обслуживания (SLA);

• Организация процессов управления услугами в области ИТ;

• Регламент аудита процессов управления информационными технологиями.

Стандарты в области управления проектами (на базе ANSI PMI PMBOK GUIDE 2000, ИСО/ТО 10006)

• Классификатор ИТ-проектов;

• Порядок формирования и выдачи децимального номера на техническую документацию в ИТ-проектах;

• Регламент и методическое обеспечение деятельности по управлению портфелем проектов;

• Регламент и методическое обеспечение деятельности по управлению программой работ;

• Регламент и методическое обеспечение деятельности по управлению ИТ-проектом;

• Комплект типовых положений о структурных образованиях, участвующих в управлении портфелем проектов, программой работ и ИТ-проектом;

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

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

Стандарты управления качеством в области ИТ

• Концепция создания и развития системы качества предприятия;

• Перечень государственных и международных стандартов, рекомендованных к применению в системе качества;

• Руководство по качеству;

• Процессы и процедуры обеспечения и контроля качества в системе качества;

• Организация и проведение нормоконтроля документации на автоматизированные системы и программные средства;

• Организация и проведение аудитов и проверок системы качества.

Стандарты документооборота в области ИТ

• Порядок выдачи задания генеральному подрядчику и соисполнителям работ в области ИТ;

• Типовые формы текущей и итоговой отчетности по работам в области ИТ;

• Комплект документации по информационным системам;

• Комплект документации по телекоммуникационным системам;

• Порядок хранения и тиражирования документации;

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

• Общий порядок внесения изменений в документацию.

Показать полностью… https://vk.com/doc-128381368_438865608
413 Кб, 11 ноября 2016 в 14:31 - Россия, Москва, МЭСИ, 2016 г., ppt
Рекомендуемые документы в приложении