Совершенствования систем управления и информационных систем их поддержки

Начальный (первичный) вход — главный вход субпроцесса, который одновременно является выходом предыдущего процесса или главным входом в общий технологический процесс. У субпроцесса, как правило, имеется один вход.

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

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

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

Исполнитель — должностное лицо, которое участвует в процессе.

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

Информация — поля регистров и/или документы, которые формируются в результате действий исполнителей.

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

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

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

В качестве примера ниже представлены итерации брокерской сделки:

заключение агентского соглашения;

перечисление клиентом денежных средств брокеру;

формирование поручения на сделку;

заключение брокером сделки;

подтверждение сделки контрагенту и клиенту;

подготовка и заключение договора по сделке;

перерегистрация собственности на ценные бумаги;

оплата ценных бумаг;

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

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

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

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

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

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

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

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

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

Следует отметить, что РБП не следует смешивать с другими известными подходами к совершенствованию управления, среди которых следующие:

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

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

Реструктурирование (restructuring) — уменьшение размерности (downsizing). Эти термины обозначают уменьшение возможностей компании, например снижение производственных мощностей для соответствия текущим более низким требованиям. Реинжиниринг же всегда стремится сделать больше, а не меньше.

Реорганизация (reorganizing) — «выравнивание организации» (flattening), хотя «выравнивание» вполне может оказаться и результатом проведения реинжиниринга. Однако в отличие от реорганизации и выравнивания, имеющих дело с организационными структурами, реинжиниринг имеет дело с процессами.

Улучшение качества (quality improvement — QI), глобальное управление качеством (Total Quality Management — TQM). Хотя и реинжиниринг, и управление качеством отводят центральную роль бизнес-процессам, между ними существует принципиальное отличие: управление качеством принимает имеющиеся процессы и старается их улучшить, в то время как реинжиниринг заменяет существующие процессы на новые.

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

1.4 Связь бизнес-реинжиниринга и информационных технологий

1.4.1. Информационные технологии как основа реинжиниринга

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

Рис. 1.8. Схема глобализации бизнеса на основе ИТ

Новые ИТ служат технологической платформой РБП на

предприятии. Корни взаимосвязей ИТ и РБП состоят в том, что

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

Рис. 1.9. Модель взаимодействия бизнес-структур и ИТ Дж. Хендерсона

Влияние реконструкций бизнес-процессов на новые ИТ-архитектуры отражает модель Дж. Хендерсона (рис. 1.9), в которой определены:

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

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

основная ИТ-платформа — ряд адекватных компьютерных технологий, которые могут быть доступны предприятию, и способы, которыми эти технологии могут быть использованы для повышения конкурентоспособности;

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

Модель Дж. Хендерсона позволяет сделать следующие выводы:

существует взаимодействие основных бизнес- и ИТ-платформ;

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

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

В табл. 1.2. представлено взаимное соответствие бизнес-архитектуры и ИТ-архитектуры организации.

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

Сопоставление бизнес- и ИТ-архитектуры в современных условияхБизнес-архитектура                            IT-архитектура

Автоматизация подразделения                            Различные поставщики оборудования, сети, платформы, операционные системы

Меньшее количество уровней управления                            Электронная почта, телеконференции

Реорганизация работы с переориентацией на процессы                            Переход от OLTP-мониторов к менеджерам процессов

Интеграция цепочки поставщиков                           

Приложения клиент-сервер от нескольких поставщиков

Многопротокольная маршрутизация

Надежная передача сообщений

Глобализация                           

Портированность приложений различных производителей

Глобальные сети

Бесперебойная 24 х 365 работа

Интенсивная фокусировка на обслуживание клиента                           

Быстрое развитие приложений

Приложения клиент-сервер от нескольких поставщиков

Надежная передача сообщений

Бесперебойная 24 х 365 работа

Возросшая мобильность рабочих                           

Беспроволочные коммуникации

Асинхронные сообщения

Рост телекоммуникаций                           

Тиражирование баз данных

Бесперебойная 24 х 365 работа

Интенсивная фокусировка на стоимости                            Использование новейших технологий

Таким образом, могут быть сделаны следующие выводы.

Методы проектирования ИС должны обладать гибкостью для обеспечения живучести предприятия в условиях бизнес-реинжиниринга.

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

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

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

Методология и методы проектирования должны радикально

отличаться от классических.

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