<< Пред. стр. 10 (из 14) След. >>
Список литературы по разделу
Управление реальными событиями в бизнесе:
2. Управление управлением
3. Управление полномочиями
4. Управление результатами производства
5. Управление достижениями
6. Управление производительностью
7. Управление качеством
Управление реальными ситуациями в бизнесе:
8. Управление хранением
защита
- отчеты по счетам
управление контрактами на поставку материалов, включая деловые вопросы
продажи в убыток и приобретения
инвентаризация
Управление обработкой данных:
9. Информационное управление
- включая управление использованием контрактов на поставку материалов
• управление техническими функциональными подразделениями
• управление полномочиями
• вспомогательные меры
• определение количественных значений
- проверка ожидаемых (ex ante) данных
- дублирование документации и дальнейшая обработка
- наблюдение и руководство
Управление стандартами, используемыми в средствах контроля:
10. Управление стандартами
Управление проектированием и следования внутренней системе управления:
11. Составляют ли правила эффективное и производительное целое?
12. В достаточной ли мере выполняются правила?
Рисунок 5.Е Факторы информационного управления
формулируются требования к информационному управлению, вытекающие из требований клиентов или выпущенных законов и правил.
Точное определение основных мер информационного управления часто происходит позднее, уже в ходе разработки процессов. Однако важно еще на ранней стадии выявить меры информационного управления, так как они оказывают влияние на архитектуру данных (например, создавая избыточную документацию данных из опасения, что ее будет недостаточно) и архитектуру процесса (например, путем объединения контрольных операций).
Меры, которые необходимо выбрать для информационного управления, должны быть отлажены в соответствии друг с другом. Меры информационного управления иногда называются системой (см. также Раздел 4.8). Необходимо учитывать и факторы информационного управления, представленные на Рисунке 5.Е.
5.5 Мероприятие 3: Проектирование логической структуры
В данном мероприятии проектирования проводится обзор административно-организационной системы. Использование информации, требования, предъявляемые к системе информационного управления, и соответствующие средства информационного управления определяют окончательный проект процесса. Мы займемся вопросом обработки требований для их использования в проектировании административной системы. Логическое проектирование включает следующие элементы, начиная с указанных на Рисунке 5. А:
* Концептуальную модель данных (h).
* Иерархический обзор административных бизнес процессов (i).
* Дополнительный, более подробный анализ связей между моделью данных и административными бизнес-процессами (j).
5.5.1 Концептуальная модель данных
В Разделе 5.4 указывается, как составлять определения данных (h). Составление этих определений будет продолжено в фазе логического проектирования. В то же время, в течение этой процедуры будут установлены свойства приложений, для которых нужны данные, и отношения между этими приложениями. Для целей данной книги нет необходимости рассматривать вопросы моделирования данных в большом объеме; по этому предмету опубликовано достаточно много хорошей литературы.
5.5.2 Иерархический обзор административных
бизнес-процессов
Иерархический обзор административных бизнес-процессов (i) может дать понимание структуры и состава административной системы. Он демонстрирует внутреннюю иерархию административных бизнес-процессов в связи с функциями этой системы. В связи с этой функцией проводится целенаправленный обзор целей информационного управления (см. также Приложение III).
Мы сейчас рассмотрим тот факт, что исходя из бизнес-процессов, можно описать организованную иерархию процесса обработки данных с целью сформировать ожидания о приложении информации (описание см. в Разделе 5.4). Также выделяются процессы, являющиеся компонентами па-бора средств информационного контроля (описанных в мероприятии 2).
5.5.3 Связи между моделью данных и
административными бизнес-процессами
Модель данных и административные бизнес-процессы вместе составляют единую информационную систему (j). Во время фазы логического проектирования между этими двумя понятиями должна существовать четкая связь. Административные бизнес-процессы есть процессы обработки данных, во время которых проводится сбор и регистрация основных данных. Они подвергаются немедленной обработке или же хранятся некоторое время, а затем обрабатываются. После обработки они могут быть распространены сразу же или после периода хранения.
Таким образом, процесс охватывает ввод базовых данных и получение на выходе обработанных данных. Процесс должен быть организован так, чтобы на основе входных данных можно было получить требуемый результат на выходе. С помощью этого метода можно выделять мероприятия административной системы в соответствии с моделью данных.
Методика, применяемая к этому процессу, состоит в построении схемы информационных потоков. Эта методика стала известна как инструмент при разработке автоматизированных систем. Схема принципов административных бизнес-процессов (см. Приложение II) довольно часто используется в качестве схемы информационных потоков аналогичным образом.
С помощью схем информационных потоков или схем принципов анализируются методы создания выходных данных (требований к информации) из базовых данных, введенных ранее. Схема составляется таким образом, что входные и выходные данные изображаются в виде стрелок,
Рисунок 5.F.1 Схема информационных потоков: расчет финансовых смет на реализацию
Рисунок 5.F.2 Определение детализации схем информационных потоков
направленных к административным бизнес-процессам и от них. Реальный процесс изображается в виде круга. Хранилище данных изображается в виде маленького "контейнера". Ввод данных в файл или их вызов in файла отмечается стрелкой.
Хранилищам данных, информационным потокам и административным бизнес-процессам присваивается каждому уникальное имя. Опреде-
ления сохраняемых данных и информационных потоков должны находиться в каталоге данных (словаре данных). Процессы должны быть включены в иерархический обзор процессов, чтобы ясно представить внутренние взаимосвязи.
Если на определенном уровне схема уже не дает достаточного понимания, то детали процессов и информационные потоки необходимо далее определять в повой схеме. Таким образом, постоянно соблюдается соответствие между более общими, широкими схемами и детальными схемами.
Детализация схем продолжается до тех пор, пока мероприятия по обработке данных не будут описаны точно и однозначно на самом низком требуемом уровне. На Рисунках 5.F.1 и 5.F.2 показаны примеры использования схем информационных потоков.
5.5.4 Другие элементы процессов
Для каждого процесса необходимо указать событие, положившее начало административному бизнес-процессу, и точку, на которой процесс считается завершенным. Началом может послужить получение заказа, счета-фактуры, формы ходатайства или истечение договора о найме. Конечной точкой процесса может стать отправка заказа, отправка платежа, объявление об истечении срока ходатайства или отправка компенсации уходящему работнику. Иногда административный бизнес-процесс расширяется. Какое-либо мероприятие может так и не быть завершено. С поступлением заказа будет зарегистрирована информация об отправке, товары будут отправлены, счет будет составлен, но из-за ошибки в бухгалтерии счет может оказаться посланным не в ту организацию и в результате так и не быть закрыт.
Для каждого процесса следует определить периодичность, с которой процесс должен выполняться. Для этой цели нужно использовать частотную таблицу. Для каждого процесса должна также быть сделана количественная оценка. Для этого необходимо провести количественный обзор.
Следует подумать об использовании специальных инструментов в административных мероприятиях в ситуациях, когда они увеличивают производительность, улучшают надежность или сокращают длительность цикла процедур обработки данных. При оценке мероприятий, для которых эти инструменты могут эффективно использоваться, рекомендуется применять количественный обзор и частотные таблицы. Один из возможных инструментов относится к автоматизированной/компьютеризированной обработке данных. В Разделе 5.8 описана связь между рассмотренным ниже проектом и разработкой системы.
5.6 Мероприятие 4: Проектирование физической структуры
Проектирование физической структуры административных бизнес-процессов (см. Рисунок 5. А.) включает следующие вопросы:
* Какие организационные единицы должны осуществлять мероприятия по обработке данных.
* Какие мероприятия должны быть включены как часть административного бизнес-процесса и какова должна быть последовательность действий в административном бизнес-процессе.
* Какие файлы и формы данных являются необходимыми.
* Подробное описание процесса, соответствующих рабочих инструкций и разметок форм и файлов.
* Затраты и длительность цикла проектируемого процесса.
Для физической разработки административных бизнес-процессов важно иметь хорошую иллюстрацию различных аспектов подхода (переменных проекта). Решения, упомянутые выше, непосредственно влияют на выполнение заданных требований. Полный спектр возможных переменных проекта достаточно велик. На Рисунке 5.G представлена выборка, которая, по-видимому, работает на практике. Эти переменные являются результатом мероприятий 1, 2, и 3 (см. раздел 5.2).
Постоянно создается впечатление, что различные переменные проекта противоречат друг другу. В этом случае необходимо сделать правильный выбор приоритетов, которые будут применяться к различным переменным проекта. Разумно также указать минимальные требования в отношении других переменных проекта. Набор приоритетов будет зависеть от требований клиента и требований, установленных законом, характера процесса управления, организационной структуры, и т. д.
5.6.1 Распределение мероприятий по организационным единицам
Когда иерархический обзор объединяется со схемой организационной структуры, образуется полный обзор организационных единиц (см. матрицу в Приложении IV). С помощью этой матрицы можно определить степень причастности конкретной организационной единицы к конкретному административному бизнес-процессу.
Возможно, что в отношении конкретных мероприятий сформированы какие-либо административно-организационные условия. В первую оче-
Дата:
1- 1G- 1992
Код докумеша:
Проект;
Адм. организация
Фаза проекта:
Проектирование административного процесса
Команда, работающая над проектом:
Трудовые ресурсы
Предметная область:
Проектирование административной обработки при найме на работу новых сотрудников
Составитель документа:
Дж. де Корте
Предмет:
Базовые мероприятия
№
п/п
Базовое мероприятие
Описание
Результаты
№ формы
Исполнитель
А
Заполнение регистрационной и налоговой форм
Регистрационная форма должна включать все данные, необходимые для обработки найма на работу новых сотрудников
Заполненные: - регистрационная форма для работника - налоговая форма
1 2
Труд. рее. Работник
В
Заполнение регистрационной формы и контракта
Ввести денные отдела и завизировать договор о трудоустройстве работника
Регистрационная форма, заполненная данными отдела и завизированная
1
Менеджер отдела
С
Проверка заполнения
Проверка заполнения регистрационной формы
Контрольная виза на регистрационной форме
1
Труд. рее.
D
Запрос на медицинский осмотр
Запрос на медицинский осмотр в медицинской службе компании
Форма запроса
3
Труд, рее
Е
Письмо-договор
Составить письмо-договор
Напечатанное, но еще не подписанное письмо и копия
4
Труд. рее.
F
Получение результатов медицинского осмотра
Возврат полученной формы запроса с результатами осмотра
Заполненная форма запроса
3
Труд. рее.
G
Заведение личного дела
Завести номер файла и приготовить файл
Файл личного вела
5
Труд. рее.
Н
Заявка на медицинскую страховку
Заполнение и отправка формы медицинской страховки
Форма страховки
6У7
Труд. рее.
I
Мониторинг финансовой сметы
Обновление таблицы должностей, проверка утверждения вакансии
Обновленная таблица должностей
8
Отдел финансово го планирова ния
J
Ввод в платежную ведомость
Заполнение карточки учета рабочего времени Запись в таблицу платежной ведомости
Карточка учета рабочего времени Таблица платежной ведомости
9 10
Отдел труда и зарплаты
К
Заявка на пенсионную страховку
Заполнение и отправка письма с заявлением
Письмо-заявление
11
Труд. рее.
Enz..
Рисунок 5.G Пример обзора базового мероприятия
редь, эти условия могут быть связаны с местом проведения мероприятия.. Следующие условия должны быть включены и заданы:
* Конкретные мероприятия должны выполняться сотрудниками или отделами, определенными заранее.
* Некоторые мероприятия должны быть объединены друг с другом в одном отделе.
* Некоторые мероприятия не должны быть объединены в одном отделе или поручены одному сотруднику.
* В административном бизнес-процессе определенные наборы да 11-ных необходимо обновлять или делать на них ссылки.
Кроме того, административно-организационные условия могут быть связаны с созданием, обработкой, ссылками и удалением каких-либо наборов данных.
Учитывая переменные проекта, матрица может указать, где именно (рабочее место [отдел]) будет выполняться упомянутое мероприятие. Место (отдел) выполнения конкретного мероприятия обозначено на Рисунке 5.С. Если заранее было определено, что мероприятия будут выполняться несколькими отделами, то на этой стадии происходит дальнейшее нетление мероприятий.
Чтобы указать место проведения мероприятий, необходимо уже иметь некоторое представление об их организационном группировании. При запуске нового процесса, который должен заменить ранее применявшийся процесс, следует рассмотреть связи в пределах существующей структуры. В полностью и вновь разработанной организации можно найти связи с описаниями характеристик бизнеса и на этом основании определить ожидаемую компоновку организационной структуры.
Существует несколько критериев, которые могут играть роль в определении места проведения мероприятий:
* Достижение наиболее эффективного использования применяемых наборов данных.
* Осуществление оптимального использования инструментов, применяемых в административных бизнес-процессах.
* Размещение мероприятий таким образом, чтобы мероприятия с самой большой организационной взаимосвязью как можно больше проводились вместе.
* Размещение задач, похожих друг на друга и требующих приблизительно равного уровня образования, по возможности вместе.
*
Разделение функций распоряжения, выполнения, хранения, документирования для реализации оптимального уровня управления.
* Составление наборов задач так, чтобы достичь хорошей степени удовлетворения работой. Содержание и условия работы должны обеспечивать оптимальное количество разнообразия и самоуправления. Чтобы создать хорошую мотивацию для служащих, вы должны стремиться создавать комплексные наборы задач так, чтобы максимально использовать способности вовлеченных сотрудников. Также важно, чтобы группы были сформированы из людей, подходящих друг другу по интересам, характеру и образованию.
Различные критерии могут противоречить друг другу. Иногда преобладает один или несколько критериев. Следовательно, остальные играют меньшую роль в организации структуры. Если лишь немногие критерии преобладают или не преобладают никакие, то ищут баланс. Характеристики бизнес-процесса и требуемая информация для управления им в конечном счете определяют приоритет критериев.
Вы можете получить некоторое представление о том, как достигается баланс, оценивая степень выполнения каждого критерия для каждой из альтернатив. Альтернатива с самым высоким итоговым счетом является предпочтительной до тех пор, пока она не опускается ниже минимального уровня любого из индивидуальных критериев. Определение места проведения мероприятий носит предварительный характер, поскольку возможно, что оно будет определяться на основе следующих этапов проектирования.
5.6.2 Определение последовательности мероприятий в процессе
Мероприятия, которые вызваны одним и тем же событием (инициирующим событием) и имеют одинаковую периодичность, могут быть включены в один и тот же административный бизнес-процесс в качестве его частей. В других случаях, более разумным с точки зрения длительности цикла является проектирование процессов таким образом, чтобы они проводились параллельно, а не последовательно.
Порядок административных бизнес-процессов может быть получен из логической структуры и обработки данных, введенных в мероприятие. Они могут быть представлены на Рисунке 5.Н. Порядок можно получить из схем информационных потоков. Если они достаточно сложны, то для каждой частоты и начального события необходимо внести мероприятия в схему, пример которой изображен на Рисунке 5.1. Эта схема еще раз
* Эффективное информационное управление:
- актуальность
-диапазон качества
* Файлы данных
* Структура задач и должностей
* Эргономика
* Внутренний контроль:
- средства
- меры
* Маршрутизация
* Возможности для автоматизации
* Факторы производительности
* Продуктивность
* Инструменты
* Степени свободы
Рисунок 5.Н Основные принципы проектирования административных бизнес-процессов
указывает, какие данные необходимы для конкретного мероприятия (О) и какие данные создаются или обрабатываются во время мероприятия (X). Порядок мероприятий теперь можно определить из Рисунка 5.G, так как фиксируется каждое мероприятие и каждое информационное свойство (с помощью X и О), при использовании как информации из предыдущего мероприятия, так и информации, не связанной с мероприятием.
Мероприятие может выполняться лишь после того, как факт завершения мероприятий, отмеченных О в столбце свойств, будет зафиксирован как X. Порядок мероприятий вводится в последний столбец Рисунка 5.J.
5.6.3 Определение необходимых файлов данных и форм
Если таблица на Рисунке 5.J заполнена, то документы, необходимые для обмена данными между различными мероприятиями, можно определить из таблицы на Рисунке 5.1. Данные, созданные в первом мероприятии, записываются в документе 1. Этот документ отмечен в столбце "выходные документы" (столбец 29 Рисунка 5.1). Кроме того, там, где применима информация из документа, это отмечается в столбце "входные документы" (столбец 28). Входные документы для всего мероприятия отме-
Дата:
7-16- 1992
Код документа:
Проект:
Адм. организация
Фаза проекта:
Проектирование административного процесса
Команда, работающая над проектом:
Сотрудники
Предметная область:
Настройки административной обработки
Составитель документа:
Предмет:
Информационные свойства
Рисунок 5.1 Пример начального анализа информационных свойств
Дата:
1-15- 1992
Код документа:
Проект:
Адм. организация
Фаза проекта:
Проекпшрованио административною процессе
Команда, работающая над проектом:
Сотрудники
Предметная область:
Настройки одминистротичной обработки
Составитель документа:
Дж. де Корте
Предмет:
Обзор последовательности
Рисунок 5.J Пример обзора последовательности мероприятий
чены тем же способом, Если для конкретного мероприятия отмечены наборы данных, то эта информация должна также быть зафиксирована в столбце ввода. Существующие документы должны быть отмечены в обзоре всюду, где они используются в административном бизнес-процессе. Если в одном из входных документов приводятся более определенные данные (визы, дата мероприятия и т.д.), то число заполненных документов указывается в скобках в столбце 29. В мероприятии Е составляется письмо с предложением работы (Номер 4), дата письма отмечается в регистрационной форме (Номер 1), которая предоставила базовые данные для письма. В мероприятии L директор подписывает письмо, а дата подписания письма отмечается в регистрационной форме. Заполнение таблиц 5.1 и 5.J представляет собой итеративный процесс. Перенос разработки базовых положений из таблицы 5.G в таблицу 5.1 приводит к корректировке таблицы 5.J и наоборот. Часто это необходимо для того, чтобы еще раз заполнить таблицу 5.1 (на сей раз более детально). В принципе, порядок различных мероприятий, документов и используемых в них наборов данных должен быть ясен после завершения вышеупомянутой процедуры. На основе обзора в таблице 5.J можно проектировать глобальную схему административного бизнес-процесса. Приложение V далее описывает эту схему.
5.6.4 Определение детализации процесса, нацеленного на будущее
Исходя из информации, полученной в ходе предыдущих мероприятий, можно разработать административные бизнес-процессы, изображенные на Рисунке 5.А. Эта разработка будет состоять из:
* Детальной схемы процесса. Здесь определяется детализация до уровня мероприятия/задачи. Для каждого мероприятия точно описывается необходимая для него информация, где ее можно найти и куда она поступит. Более подробно детальная схема процесса описана в Приложении VI.
* Разработки формы и файла. Здесь более подробно задается компоновка наборов данных и документов, используемых в административном бизнес-процессе. Руководство по проектированию документов представлено в Приложении IX.
* Других видов документирования по административному бизнес-процессу. Рекомендуется также составить схему инструкций (см. Приложение VII). Все другие возможные виды документирования нового административного бизнес-процесса также составляются во время этого мероприятия.
5.6.5 Вычисление затрат и длительности цикла
Оценка времени делается для каждого из заданных мероприятий по время проектирования новых административных бизнес-процессов. Кроме того, указывается категория служащих (или сотрудников), выполняющих мероприятие. После этого для каждой категории служащих (или для отдельного сотрудника) рассчитываются затраты в единицу времени. 11с-ремножая время, затраченное на мероприятие, на затраты в единицу времени, получим затраты на мероприятие. Сложив все затраты, получим общую стоимость административного бизнес-процесса в целом. Естественно, что эти затраты должны возрастать с добавлением затрат на инструменты, материалы, накладные расходы, и т. д.
Если необходимо сделать оценку длительности цикла за шаг, то оценка делается исходя из:
* Времени, которое требуется на выполнение конкретного мероприятия.
* Возможных задержек, которые возникают из-за накопления сверхурочной работы.
* Времени, которое необходимо для коммуникации между различными мероприятиями. Сюда входит время, необходимое для внутренней транспортировки, время, необходимое внешним властям для реакции на письма, отправленные внутренними подразделениями, и т. д. На основе этих оценок можно получить, представление об ожидаемой длительности цикла процесса.
5.7 Внесение изменений в административные бизнес-процессы
Методы, с помощью которых реализуются требуемые улучшения, достаточно редко определяются в ходе анализа административного бизнес-процесса. Важно установить систему измерений, которая может использоваться для измерения результативности основных изменений, вносимых в административные бизнес-процессы. Также важно четко определить ожидаемые показатели деятельности до внесения изменения так, чтобы результаты могли быть определены количественно и можно было провести оценку изменения.
Как часть разработки рекомендуемых изменений, особенно важно знание степени изменения существующего процесса. В самой простой ситуации изменения ограничатся одним процессом и его выполнением в од-
ном отделе. Глобальное документирование процесса (например, полный обзор процессов н отделов, общая схема процесса и иерархическая схема, рассмотренная в Главе 3) не нуждается в изменении. Достаточно изменить детальную документацию (детальную схему процесса, инструктивную схему и т. д.). Ситуация усложняется, если изменение охватывает множество отделов и, возможно, множество процессов. В этом случае необходимо изменить не только детальную, но и глобальную документацию.
Степень изменения существующего процесса определяет количество существующих описаний, которое можно использовать. Величина изменения и его воздействие на организацию влияют на способ изменения процесса. Последствия предложенных модификаций осознаются быстрее, когда речь идет о мелких изменениях, чем когда изменения охватывают достаточно большое число отделов или процессов. Внесение изменений в существующий проект административных бизнес-процессов должно проводиться по следующим этапам:
* Сформулировать принципы изменений.
* Определить сущность изменений.
* Определить наилучшее нацеленное на будущее решение.
* Разработать детали изменений в соответствии с выбранной методикой документирования.
За разработкой изменений последует описание условий, которые необходимо выполнить для успешного функционирования измененных процессов. Также будут сформулированы различия между текущими процессами и нацеленными на будущее процессами. Кроме того, будет описано, каким образом нацеленные на будущее процессы дают решение для проблемных областей в существующих процессах.
5.7.1 Формулировка принципов
Далее необходимо определить, какие именно результаты будут достигнуты благодаря изменениям процесса. Для каждого (под)процесса нужно сопоставить следующие моменты:
* Степень, в которой цели достигаются в текущей ситуации (модель "как есть").
* Описание расхождения, обнаруженного между желаемой и действительной ситуацией.
Следует сформулировать цели, которые можно достичь путем изменений. При этом определяются не только цели изменений (в отношении улучшения точности и полноты обработки данных, уменьшения длительности цикла и т. д.), но и устанавливаются конкретные стандарты. При работе над желаемым изменением процедур обработки данных необхо-
димо будет укачать те данные, для которых производится улучшение, а также назвать конкретные используемые критерии (в отношении полноты, точности и т. д.). В случае, если желаемое улучшение относится к длительности цикла, необходимо задать длительность цикла, которую планируется реализовать (в часах или рабочих днях).
Изменение процесса подвержено влиянию многих организационных условий. Эти условия могут относится к месту, где должны проводиться мероприятия (например, файлы личных дел сотрудников должны вестись в регистратуре), к выбранной комбинации мероприятий (например, отдел кредиторской задолженности должен санкционировать поставки), к занятости в процессе конкретных сотрудников (например, менеджер должен утверждать расходы) и т. д. Условия могут также включать использование наборов данных и применение средств компьютеризованной обработки данных (например, если выписка счетов-фактур для различных отделов продаж производится на одном центральном компьютере и к вводимым документам и процедурам применяются очень строгие правила). Такие организационные условия, составляющие часть формулировки базовых принципов, необходимо корректировать. Иногда организационные условия являются настолько строгими, что их невыполнение влечет за собой невозможность достижения намеченных целей. В этом случае продолжение разработки модификаций, очевидно, будет бессмысленным. Перед тем как тратить на планирование модификаций дополнительные усилия, необходимо изменить либо организационные условия, либо цели процесса.
После согласования целей процесса и организационных условий можно продолжать дальнейшую разработку модификаций. Сначала определяются те существенные компоненты текущих процессов, которые нужно менять, а затем те, которые нужно оставить без изменения.
5.7.2 Определение сущности модификаций
Для определения сущности модификаций необходимо иметь документацию о существующих процессах, которые будут модифицироваться. В документации должны быть указаны:
* Мероприятия и задачи, составляющие процесс.
* Порядок выполнения этих мероприятий и задач.
* Место проведения мероприятия.
* Данные, которые должны быть получены в результате процесса.
* Информация, задействованная в процессе.
* Нормативы процесса.
Все эти задачи будут зарегистрированы и процессе мероприятий по документированию процесса. На основе этих документов можно изучить изменения, вносимые в процесс, используя сформулированные проблемные области, основные предположения и цели.
Иногда из результата анализа мероприятий становится ясно, какие именно из упомянутых факторов нужно изменить. Если оценка средств информационного управления показывает непригодность функционального разделения, то мероприятия или задачи следует перевести из одного отдела в другой (или от одного сотрудника к другому).
Отношение между желаемым результатом и изменением, которое необходимо внести, не всегда ясно. Иногда для достижения желаемой цели сначала требуется провести дополнительное исследование характера вносимых изменений. Это в первую очередь относится к ситуациям, когда возможно несколько альтернативных изменений административного бизнес-процесса. При разработке нацеленного па будущее решения, нужно рассмотреть множество комбинаций подходов к улучшению (например, при поиске решения для увеличения возможностей обработки, эффекта от всех видов инструментов, показателей одновременного выполнения задач или мероприятий, при устранении мероприятий, и т. д.). В некоторых ситуациях разрабатываются и анализируются сразу несколько альтернативных нацеленных на будущее решений.
Для каждого потенциального нацеленного на будущее решения устанавливается степень вклада изменения в реализацию заданной цели. Кроме того, следует рассмотреть последствия задач и мероприятий (место, порядок и т. д.), использование информации (нужна ли другая информация или нужна ли данная информация на другой фазе), информацию, которую необходимо получить, а также затраты и длительность цикла, необходимые для внедрения потенциального решения.
Необходимо наметить организационные последствия изменений. В то же время, следует сделать попытку составления картины влияния изменений на затраты и скорость обработки.
Лучше всего будет разработать несколько концептуальных нацеленных на будущее решений. Каждое потенциальное нацеленное на будущее решение может быть проанализировано путем построения предварительной модели процесса и апробирования ее с целью проверки того, что:
* Нет проблем с взаимодействием.
* Система работает в соответствии с ожиданиями.
* Не появилось непредвиденных проблем.
Обычно построение модели на этом этапе представляет собой либо компьютерное, либо физическое моделирование или же комбинацию этих двух видов.
В современных условиях моделирование с помощью компьютерной имитации дает массу преимуществ. Существует большое количество отличных программ, которые помогут вам воспроизвести нацеленным n;i будущее процесс, не обработав при этом ни одной детали и даже не передвинув стола. Программы компьютерного моделирования в приложении к проектированию аппаратного обеспечения и производственным потокам стали популярными с середины 1970-х годов, но имитация бизнес-процессов завоевала популярность лишь в середине 1990-х.
Моделирование расположения позволяет разработчику построить правильную по масштабу трехмерную модель каждого мероприятия и соединить мероприятия вместе, различным образом варьируя входные переменные с целью определить работу процесса и выявить проблемы.
Как правило, имитация процесса представляет собой расширение процесса составления блок-схем, используемых для характеристики текущих элементов (элементов "как есть") и построения исправленных блок-схем, используемых для определения нацеленного на будущее процесса. Современные имитационные модели чрезвычайно сложны. Для имитации хода процесса в них используются иконки, чтобы определить:
* Препятствия, возникающие в ходе процесса.
* Критические пути.
* Длительность цикла.
* Время обработки.
* Проблемы, связанные с большой рабочей нагрузкой.
В таких имитационных моделях продукт изображается движущимся через процесс, в то время как иконки с изображением маленьких людей отвечают на телефонные звонки, отдыхают во время перерывов, посещают собрания и даже делают кое-какую работу. Большинство программ позволяют ускорять или замедлять ход (последовательность) процесса. Дни или месяцы хода процесса могут быть сведены к минутам в имитационной модели. Можно создавать наихудшие (пессимистичные) сценарии и анализировать их, не нанося вреда реальному процессу и не огорчая потребителя. Хорошо разработанная имитационная модель берет теорию и преобразовывает ее в суровую реальность ежедневной деятельности вашей организации. Вначале подготовка компьютеризированной имитационной модели может занять определенное время, но если изменение является существенным, то время будет потрачено не зря, и с помощью модели можно будет избежать начальных неудач.
Во многих случаях для подтверждения определенной концепции необходимо подготовить физическую модель нацеленных на будущее процессов. Это в первую очередь относится к процессам, которые представляют собой продукт или элемент, не поддающийся компьютерной имита-
ции. Такие компьютерные программы, как автоматизированное проектирование (CAD) и автоматизированное производство (САМ) оказывают огромную помощь в сокращении времени, необходимого для построения аппаратных моделей. Как правило, эти аппаратные модели подвергаются серии тестов на эффективность функционирования и на нагрузки с тем, чтобы получить подтверждение для проектируемых показателей.
Административные бизнес-процессы могут моделироваться физически. Этот вид моделирования называется моделированием в конференц-зале. В таких случаях подготавливают макеты компоновки, терминалов, клавиатур, форм и оборудования. Если в нацеленное на будущее решение включено коммерческое программное обеспечение, то оно используется в ходе операции моделирования. Новое, некоммерческое программное обеспечение имитируется вручную, создавая лишь внешнюю иллюзию того, что оно уже написано. Моделирование процесса часто требует существенной скрытой поддержки для того, чтобы создать иллюзию нацеленного на будущее процесса.
В результате мероприятия моделирования определяются многие проблемы и возможности по улучшению, в соответствии с которыми следует обновить и улучшить нацеленное на будущее решение. К концу фазы моделирования должна быть четко определена целесообразность каждого будущего решения и риска, связанного с его физической реализацией.
Утверждение нацеленного на будущее решения
Теперь пришло время согласовать каждое из потенциальных нацеленных на будущее решений с собственниками и определить, какое решение они предпочитают. Это означает, что команда по улучшению процесса должна покинуть свою "башню из слоновой кости" и встретиться с потребителями, служащими, менеджерами и поставщиками. Утверждение может проводиться при помощи фокус-групп; однако не рекомендуется формировать смешанные фокус-группы (администрация, поставщики, потребители, и т. д.). Цель совещаний этих фокус-групп - определить, есть ли у участников какие-либо предложения по дальнейшему улучшению решений, и дать им провести оценку того, какое из нацеленных на будущее решений лучше всего удовлетворяет их потребностям. Фокус-группы потребителей/покупателей являются главными резонаторами, так как одна из основных целей проведения исследования по улучшению бизнес-процессов состоит в росте потребительского удовлетворения. Если нацеленное на будущее решение не отвечает требованиям покупателей, то в дальнейшем движении почти нет смысла. Фокус-группы потребителей должны уделить основное внимание тому, как на них скажется улучшенная работа рассматриваемого элемента.
Следующий ряд фокус-групп должен состоять из менеджеров среднего звена. Следует отобрать менеджеров, которые будут нести ответственность за работу элемента. Этим фокус-группам команда по улучшению процесса должна представить все достоинства каждого из потенциальных нацеленных на будущее решений. После такого рода совещании следует совещание с работниками и поставщиками. В обоих случаях команда по улучшению процесса должна представить все преимущества каждого из потенциальных нацеленных на будущее решений, но основной акцепт следует сделать на том, как каждое из этих решений повлияет на отдельных членов фокус-группы. От поставщиков обычно исходит особенно много идей по улучшению.
Все потенциальные нацеленные на будущее решения должны быть представлены на этих совещаниях фокус-групп таким образом, чтобы участники могли оценить каждое из них. Это позволяет получить чрезвычайно ценные данные, которые окажут неоценимую помощь при выборе наилучшего нацеленного на будущее решения.
Иногда изменение процессов может иметь последствия для других процессов. Это особенно актуально для случаев, когда изменения вносятся в наборы данных, используемые многими процессами. В Главе 3 читатель найдет методики, которые можно использовать при изучении последствий предлагаемых изменений. Если для конкретной проблемы возможно множество решений, то на основе собранных и изученных данных необходимо прийти к выводу о том, какие из альтернатив являются наилучшими нацеленными на будущее решениями для организации.
5.7.3 Наилучшее по ценности нацеленное на будущее решение
В сегодняшних условиях конкуренции, при перепроектировании административного бизнес-процесса трудно выбрать наилучшее решение из-за возникновения множества возможных вариантов. Если бы у команды по улучшению процесса было только одно измерение для принятия решения, то ее работа была бы относительно несложной. Если бы команда по улучшению процесса должна была бы всего лишь спроектировать процесс с минимальным временем цикла, не учитывая никаких других факторов, то проект был бы тоже довольно простым. Они бы просто уделили основное внимание автоматизации, механизации и информационной технологии, которые минимизировали бы длительность цикла. Проблема в том, что процессы достаточно редко проектируются с целью оптимизации только одного измерения, без учета других измерений, связанных с процессом. В действительности, необходимо учесть целый ряд факторов, прежде чем организация сможет понять те выгоды, которые извлечет ак-
циопер ич отдельного нацеленного па будущее решения. Далее приведены некоторые из наиболее распространенных измерений, которые необходимо учитывать:
* Результативность нацеленного на будущее процесса.
* Эффективность нацеленного на будущее процесса.
* Адаптируемость нацеленного на будущее процесса.
* Затраты на внедрение нацеленного на будущее процесса.
* Длительность цикла, необходимая для осуществления нацеленного на будущее процесса.
* Риски, связанные с нацеленным на будущее процессом.
Становится очевидным, что имея эти шесть факторов, оказывающих влияние почти на все нацеленные на будущее решения административных бизнес-процессов, очень трудно определить, является ли отдельное нацеленное на будущее решение действительно наилучшим для организации, если в анализ включается только оно. Если удалить из процесса бюрократию, то сократится длительность цикла и затраты, что может оказать негативное влияние на качество продукта, получаемого в процессе. Более сложный пример: нацеленное на будущее решение, которое полностью автоматизирует процесс, уменьшая длительность цикла и уровень ошибок, но требует 3 миллиона долларов и 24 месяца на его реализацию, в то время как улучшенный ручной процесс мог бы быть реализован за 50 тысяч и в течение шести месяцев. Ручной процесс обеспечил бы 80% от выгод автоматизированного будущего решения. Так какое же из этих двух нацеленных на будущее решений следует внедрить организации? Честно говоря, единственно верного ответа не существует. Все зависит от того, какой процесс улучшается, и какое влияние окажет изменение на всю деятельность организации. Что правильно для одной организации, часто оказывается неправильным для другой.
Можно разработать ряд нацеленных на будущее решений, основанных на различных целях. Типичными примерами формулировки различных целей для одного и того же процесса являются следующие вопросы:
* Насколько улучшатся показатели по длительности цикла и затратам, если нацеленное на будущее решение необходимо реализовать в течение 90 дней?
* Насколько улучшится качество продукта при уменьшении длительности цикла и затрат минимум на 20%?
* Насколько улучшатся показатели по длительности цикла, затратам и качеству продукта, если пренебречь затратами и длительностью цикла внедрения?
* Насколько улучшатся длительность цикла и качество продукта, если прибыль на инвестированный капитал составляет минимум 12 к 1 на последующие три года?
* Насколько улучшатся все показатели, если рационализировать настоящий процесс при текущих проверенных методиках?
* Какое нацеленное на будущее решение даст наилучшую прибыль на инвестированный капитал за трехлетний период?
Ценность, как и качество, оценивается окружением. Однако при оценке ценности в расчет принимается намного больше факторов, чем при оценке качества. Нацеленные на будущее процессы, представляющие большую ценность для одной организации, часто являются неприемлемыми для другой организации. С приходом понятия наилучшего по ценности будущего состояния, понятие хорошей практики вытесняется более широким взглядом на административные бизнес-процессы. В настоящее время лишь очень редко хорошая практика, а то и вовсе никакая, является наилучшим по ценности решением для большинства ситуаций.
5.7.4 Задание детализации
В рамках проекта проводится модификация и дополнение исходных схематических описаний. Оцениваются результаты предыдущего мероприятия (см. Раздел 5.2.2) в отношении последствий изменений и определяется, соответствуют ли они по-прежнему цели изменений или же их нужно менять, дополнять или определять более детально. Необходимо выявить возможные изменения в существующих документах и файлах и разработать новые формы, планы, и т.д.
Стоит порекомендовать, чтобы в ходе фазы проектирования в изменениях, после получения одобрения, принимались во внимание записи из Справочника по административной организации.
5.8 Проектирование административного бизнес-процесса и разработка системы
С первого же взгляда создается впечатление, что между проектированием автоматизированных и ручных бизнес-процессов существует заметная разница. Эти различия присутствуют также при изучении физической разницы между ручной и автоматизированной обработкой данных.
*
При физическом проектировании ручных административных бизнес-процессов рассматриваются отделы внутри организации, географическое местоположение, маршрутизация, время передачи документов, картотеки и формы.
* При физическом проектировании автоматизированных административных бизнес-процессов рассматриваются процессоры, терминалы, принтеры, кабели, операционные системы, системы управления базами данных, и т. д.
При разработке компьютерных систем и проектировании ручного административного бизнес-процесса проектировщик старается как можно больше использовать имеющиеся средства обработки. Физические характеристики людей и машин совершенно различны, и это необходимо учитывать во всем. Именно в этой точке цикла улучшения мероприятия по изменению организации начинают окупаться.
Однако также существуют явные схожие черты между ручными и автоматизированными административными бизнес-процессами. В обоих случаях у административного бизнес-процесса есть цель: распространение информации среди тех, кто в ней нуждается. Для пользователя способ создания этой информации не имеет значения. Другими словами, пользователю все равно, проводится сбор, документирование и обработка данных, на которых базируется информация, компьютерами или людьми; пользователь будет продолжать задавать все те же вопросы. (Конечно, одно различие заключается в том, что автоматизированные методики позволяют удовлетворить требованиям распространения информации благодаря более высокой скорости и более низким затратам на использование компьютеризованных информационных методик, в то время как при ручной обработке данных эти требования могут остаться невыполненными.) Неудивительно, что первые три мероприятия по проектированию административных бизнес-процессов почти не отличаются от аналогичных мероприятий в методе разработки систем.
При разработке автоматизированных систем в конце каждой фазы, называемой проектированием логической структуры, определяется так называемая граница между людьми и машинами. Детали того, что происходит внутри границы, определяются далее специалистами по системному анализу и программистами. Они специализируются в оптимальном использовании возможностей компьютера. Детали того, что происходит вне границы, определяются далее специалистами в области ручных административных бизнес-процессов. Они специализируются в области проектирования административных бизнес-процессов в организациях. Очень важной является внутренняя координация мероприятий в обеих областях знаний. Законченная административно-организационная система должна функционировать как единое целое.
Часто системные разработчики слишком поздно приглашают экспертов по проектированию прикладных административных бизнес-процессов. В результате экспертам приходится строить процессы вокруг уже установленной компьютерной системы. Не так уж редко это приводит к частичной оптимизации и разочарованию как разработчиков, так и пользователей административных бизнес-процессов. Именно разработчик процесса, а не программист, должен нести ответственность за все мероприятия по улучшению бизнес-процессов. После рационализации процесса следует использовать информационные технологии для дальнейшего улучшения процесса.
6
Фаза V - Внедрение: Реализация решений, направленных на будущее
6.1 Введение
Вся работа команды по улучшению процесса окупает себя в течение Фазы V. Именно в это время все результаты анализа данных и творческого мышления, вложенного в разработку нацеленного на будущее решения, преобразуются в реальное улучшение деятельности. Несмотря па то что столько усилий и внимания было затрачено на проверку полноты нацеленного на будущее решения и правильности проектируемых затрат и сбережений, если решение будет плохо реализовано, то весь процесс может закончиться неудачей. В действительности, именно на этой фазе чаще всего происходят провалы проектов по улучшению бизнес-процессов. Создается впечатление, что энтузиазм и увлечение творческой частью административных мероприятий по улучшению бизнес-процессов (Фазы с I по IV) пропадает во время наиболее приземленной части - мероприятия по внедрению. Очень часто интересы руководства переключаются на новый проект, и из-за этого не соблюдаются правильные приоритеты для приведения процесса к завершению.
Другой фактор, приводящий к провалу проекта по улучшению бизнес-процессов во время мероприятия внедрения, состоит в том, что отдельные сотрудники, задействованные в текущем процессе, не были должным образом подготовлены к изменениям. И вновь мы хотим подчерк-
путь значение мероприятий по управлению организационными изменениями (ОСМ), которые следовало проводить параллельно с Фазами с II по IV. Если команда по улучшению процесса затягивает начало мероприятий по управлению организационными изменениями в административных мероприятиях по улучшению бизнес-процессов вплоть до этого момента, то она сама напрашивается на проблемы, и теперь уже будет слишком поздно для того, чтобы получить реальную поддержку и помощь от людей, которые должны осуществлять изменения. Разницу между хорошей и плохой работой по управлению организационными изменениями можно заметить по отношению людей, которые будут жить с этими изменениями (т. е. объектов изменения). Если команда по улучшению процесса хорошо справилась с работой, то объекты изменения будут говорить: "Позвольте показать Вам, как сделать так, чтобы изменение заработало", а не "Позвольте показать Вам, почему это изменение никогда не заработает".
Модифицированные или новые процессы будут вводиться в действие соответствующими менеджерами или контактными группами. В течение этой фазы руководитель проекта будет играть опорную роль. Вначале следует убедиться в выполнении различных организационных условий. Необходимо продумать следующие моменты:
* Достаточно ли имеется рабочей силы для осуществления административных бизнес-процессов.
* Достаточно ли имеется инструментов, таких как оборудование,
системы документирования и т. д.
* Модификацию существующей организационной структуры.
* Работу с сотрудниками, занятыми в процессе. (Следует заметить, что работа с сотрудниками, непосредственно вовлеченными в процесс, обсуждалась в предыдущих фазах. Здесь же рассматривается предоставление информации и инструкций сотрудникам, задействованным в процессе косвенно.)
* Управление переходом от старого процесса к новому.
* Предоставление отчетов внешним аудиторам, которые также задействованы в административном бизнес-процессе.
После внедрения процесса важно, чтобы менеджеры отделов, контактная группа и руководитель проекта провели мониторинг процесса с тем, чтобы убедиться в его правильном функционировании. Возможные непредвиденные проблемы должны решаться отдельной группой или подгруппой команды по улучшению процесса.
Во многих случаях, перед формальным началом функционирования нового процесса проводится фаза пробного запуска. В течение этой фазы работают одновременно и новая, и существующая системы (частично).
Если после выполнения приемных испытаний будущими пользователями системы новый процесс функционирует согласно ожиданиям, то старый процесс тут же прекращается. Все вопросы, касающиеся фазы пробного запуска, безусловно, должны быть уже рассмотрены во время фазы проектирования. На этой фазе на организацию будет оказано дополнительно давление из-за потребности в дополнительной рабочей силе и инструментах.
После того как новый процесс проработает некоторое время, необходимо провести оценку. Эта оценка, проводимая менеджерами отделов и контактными группами совместно с руководителем проекта, должна показать, удовлетворяет ли вновь начатый процесс всем ожиданиям. В случае необходимости процесс регулируется. Отчет о результатах оценки следует сдать команде по улучшению процесса.
Фаза V состоит из восьми мероприятий, а именно:
1. Формирование команды по внедрению нацеленного на будущее решения.
2. Разработка плана внедрения.
3. Внедрение плана на первые 90 дней.
4. Внедрение долгосрочных улучшений.
5. Проведение измерений и отчет о результатах.
6. Проведение периодических обзоров.
7. Сравнение результатов и целей.
8. Поощрение членов команды.
6.2 Мероприятие 1: Формирование команды по внедрению нацеленного на будущее решения
На Фазе IV команда по внедрению нацеленного на будущее решения может набираться как из тех же самых людей, что создавали нацеленное на будущее решение, так и из других людей. (Замечание: наилучшее нацеленное на будущее решение (BFSS) было выбрано в ходе предыдущей фазы. В оставшейся части книги наилучшее нацеленное на будущее решение BFSS будет использоваться наряду с просто нацеленным на будущее решением.) Очень часто от специалистов требуется:
* Определить проект процесса.
* Предоставить требуемое программное обеспечение и оборудование для информационных технологий.
* Провести подготовку (обучение).
*
Завершить детальное документирование.
В результате команда по внедрению нацеленного на будущее решения набирает дополнительный вспомогательный персонал. Команда по внедрению нацеленного на будущее решения (далее называемая командой внедрения) несет ответственность за три задачи, а именно:
* Внедрение нацеленного на будущее решения.
* Внедрение плана по управлению организационными изменениями.
* Измерение влияния будущих изменений.
В большинстве случаев члены команды являются отличными агентами технических изменений, но они редко осознают свою роль как агентов изменений в процессе по управлению организационными изменениями.
Первым мероприятием, которое должна провести команда внедрения, является обучение ее членов процессу улучшения, только что завершенному командой по улучшению процесса, так, чтобы у команды внедрения было полное понимание утвержденного нацеленного на будущее решения. Следующим этапом их подготовки является обучение управлению организационными изменениями, в котором особенно подчеркивается их роль как агентов изменений, связанных с людьми. Каждый член команды внедрения должен научиться содействовать изменениям в организации. Во время этого обучения будет подготовлена ролевая карта изменения проекта и определены следующие роли (см. главу 7):
<< Пред. стр. 10 (из 14) След. >>
Список литературы по разделу