Проект, который рассматривается в статье, сфокусирован на процессе запроса на изменение в информационных системах в компании Fortune 500, но может применяться в любых компаниях и отраслях. Проблема состояла в том, что время выполнения цикла запроса на изменение было слишком долгим и это не удовлетворяло требования потребителей, которые, в этом случае, являются внутренними для компании.
Основные шаги процесса запроса на изменение следующие:
- Сотрудник компании подает запрос на изменение в отдел информационных систем.
- Запрос на изменение одобряется.
- Отдел информационных систем разрабатывает изменение, тестирует и после внедряет его.
Многие из запросов на изменение от потребителей были относительно простыми, такими как выполнение изменения путем скрипта программного обеспечения или же необходимость выполнения повторного действия без повышения функциональности. Примеры включают создание новых папок, классификация по важности новых проектов или документов. До сих пор, даже простой запрос на изменение был очень длительным процессом.
Начало проекта
Время цикла для выполнения запроса на изменение увеличилось с 10 до 20 дней, когда должность в отделе информационных систем, управляющая процессом запросов на изменение, была сокращена. Временным решением было вменить выполнение дополнительных задач существующим сотрудникам отдела ИС. После четырех месяцев низкой удовлетворенности клиента, бизнес-аналитик отдела ИС попросил мастера Черного Пояса выполнить проект по улучшению относительно сокращения времени выполнения цикла.
Первой проблемой проекта было то, что в отделе ИС только несколько сотрудников были обучены принципам лин 6 Сигм. К тому же, члены команды проекта по улучшению, эксперты предметной области процесса, находились в разных географических регионах.
Чтобы увеличить шансы проекта на успех, мастер Черного пояса провел обучение относительно методологии и инструментов Лин 6 Сигм, которые будут использоваться в проекте. Также он провел семинары по решению проблем, связанных с работой проекта, скоординировав время проведения семинаров таким образом, чтобы обеспечить участие всех членов во всех регионах. Во время выполнения заданий семинара по обучению экспертов, мастер Черного пояса использовал принцип «научить-привести пример-сделать». Например, он объяснял, что такое SIPOC (suppliers-поставщик, input-вход, process-процесс, output-выход, customer-потребитель), привел простой пример и далее предложил команде создать свою схему SIPOC как группы.
Определение
Отзывы потребителей были собраны с помощью исследования и обработаны до проведения первого семинара. Исследование включало вопросы относительно качества и скорости текущего процесса. Потребители предоставили полное описание проблем, которые они испытали, и это дало команде ясную картину относительно ожиданий и требований клиента.
В дополнение к проведению исследования мнения потребителя, Черный пояс встретился в ключевыми потребителями процесса лично. Было решено, что критически важным требованием было время цикла в 10 дней, от подачи запроса на изменение и до его реализации.
| Опрос потребителя | Почему | Самое важное требование |
| Наш запрос на реализацию простого по содержанию изменения длится слишком долго. | Время цикла удвоилось и нас не волнует, почему! Начните действовать сообща. | Время цикла по выполнению запроса на изменение составляет 10 дней, от подачи запроса и до предоставления конечному пользователю. |
Также на этапе определения, команда завершила устав проекта с определенными ролями и ответственностями, провела анализ заинтересованных сторон, схемы SIPOC, а также составила схему получения выгоды (показано на рисунке 1), которая отображает бизнес-причины, по которым выбран проект и что необходимо для удовлетворения бизнес-факторов.
Рисунок 1: Схема получения выгоды Была установлена четкая связь относительно того, что ожидалось от участников до, во время и после семинаров. К тому же кроме Черного Пояса, среди участников были спонсор и проектные эксперты, которые принимали участие в процессе, а именно бизнес-аналитик, персонал отдела ИС, а также поставщик, который реализовывал изменения. Привлечение спонсора помогло с ликвидацией преград, обеспечением ресурсов и установлению положительного тона.
Такие семинары проводились еженедельно на протяжении четырех часов каждый. В качестве руководителя проекта, Черный Пояс вел эти собрания. Ранее, проведение дистанционных семинаров более чем четыре часа, показали быстрое снижение активности среди участников. Промежуток между проведением семинаров давал участникам достаточно времени для сбора необходимой информации, обсуждению с другими участниками группы и обратной отправки информации Черному поясу. Также это дало время Черному поясу коррелировать информацию, и проводить более эффективные семинары.
Измерение и анализ
Областью применения проекта был процесс запроса на изменения, начиная от времени запроса на изменения от клиента и до его реализации.
В существующем процессе, две команды в компании, по развитию проектов операционного совершенства (DPOpEx) и по развитию проектов, связанных с партнерскими отношениями (DPBP, группа, которая устанавливает взаимодействие между внутренними клиентами и отделом ИС), часто встречались для сбора требований заказчика. Примеры этих требований включали: необходимость создания электронных папок или документов, которые использовались для хранения информации, которая была необходима другим из группы потребителей. Многие из этих изменений были простыми и были подготовлены поставщиком, который отвечал за внедрение изменений.
Как показывает рисунок 2, в существующем процессе требовались многочисленные передачи выполнения и согласования. Бизнес-партнер отправлял запрос на изменение менеджеру по обеспечению отдела DPOpEx. Запрос анализировался менеджером по обеспечению относительно ясности и сравнивался с другими запросами на изменения, чтобы избежать дублирования. Потом запрос на изменение рассматривался тремя сотрудниками отдела ИС до отправки его поставщику, который потом обрабатывал изменение и проводил оценку для завершения запросов. Эта информация рассылалась разным людям для согласования. Как только все одобрили простое изменение, поставщик вносил изменения в систему. После этого, поставщик должен был отправить электронную почту двум сотрудникам DPOpEx, чтобы выполнить тестирование приемлемости для пользователей. После выполнения этого этапа, поставщику давали согласие на внесение изменения. Потом уведомлялся клиент и деловой партнер.
| DPOpEx – отдел по работе с клиентами, который переводит требования клиента группам ИС. DPOpEx взаимодействует с бизнес-партнером, менеджером по обеспечению и службой поддержки. Бизнес-партнеры представляют через DPOpEx изменения в отдел ИС, в то время как менеджер по обеспечению и служба поддержки посредством DPOpEx выполняют тестирование изменения. DPBP собирает и внедряет требования клиента. Они являются частью благоприятных для бизнеса функций. |
Данные собранные во время фазы измерения показали, что среднее время выполнения этих заказов на изменения составляло 20 дней, а при некоторых задержках - целых 45 дней.
Рисунок 2: Карта существующего процесса
| оригинал | перевод |
| Business request for change (RFC) | Бизнес-запрос на изменение |
| Write RFC | Написание запроса на изменение |
| Get RFC number | Получение номера запроса |
| Submit RFC for review | Отправка запроса на рассмотрение |
| Review RFC | Анализ запроса |
| Approve? | Одобрение? |
| Send RFC to mailbox | Отправка запроса на почту |
| Place RFC into SER form and submit | Помещение запроса в форму SER и отправка |
| Review SER. assign number and submit | Рассмотрение SER, присвоение номера и отправка |
| Process RFC and send estimates | Обработка SER и отправка для оценки |
| Receive email, ready for user acceptance test (UAT) | Получение письма, подготовка к тесту на приемлемость для пользователя (UAT) |
| Receive email, ready for UAT | Получение письма, подготовка к UAT |
| Develop/test/prepublish solution | Разработка/тест/ предварительная публикация решения |
| Perform UAT | Выполнение UAT |
| Publish and test in production | Публикация и испытание в производстве |
| In production | В производстве |
| Process and authorize payment | Обработка и разрешение оплаты |
| Send invoice | Отправка счета |
| Process and authorize payment | Обработка и разрешение оплаты |
Рисунок 3: Диаграмма Паретто, на которой представлены факторы, увеличивающие время цикла Основываясь на анализе Паретто, были идентифицированы четыре ключевые фактора, увеличивающие время цикла (рисунок 3):
- Сокращение должности менеджера по изменениям
- Неясные связи между клиентом, группой DPOpEx и отделом ИС, они не знали, на каком этапе находилось изменение.
- Недостаток прозрачности процесса
- Чрезмерное количество согласований
Команда определила основные причины, а также область потерь, связанных с ключевыми вопросами (представлено в таблице ниже).
Улучшение и контроль
Во время фазы по улучшению, команда разработала решения для сокращения потерь, связанных с основными причинами потерь (см.таблицу ниже). Восстановление должности менеджера по изменениям было невозможным из-за нехватки ресурсов. Концентрация на устранении потерь и сложности процесса показали потенциальные решения для создания эффективного процесса без привлечения дополнительных ресурсов.
Принятие решений |
| Проблема времени выполнения | Проблемы | Первопричины | Связанные потери | Решение |
| Время выполнения изменилось с 10 до 20 дней после того как был сокращен сотрудник; было принято промежуточное решение. | Прозрачность процесса | Первоначальный процесс был изменен и в процесс были вовлечены руководители, которые были не обучены должным образом. | Движение: поиск статуса изменения | Менеджеры по улучшениям процесса создали новую карту создания ценности. Эта карта и обучение было предоставлено всем участникам |
| Недостаток четких коммуникаций | Клиент и представитель клиента не знали на каком этапе находится запрос на изменение. Для определения этого представителю клиента необходимо было отсылать несколько писем | Ожидание: клиенты и бизнес-партнеры ждали изменения и/или информации о его статусе Движение: поиск статуса изменения | Основываясь на новой карте процесса, были необходимы коммуникации на специфических этапах для информирования бизнеса о статусе запроса. |
Чрезмерная передача выполнения/
документирование | Существовало слишком много передач выполнения процесса и слишком много документации, которая создавалась участниками процесса, что не требовалось. | Транспортировка: файлы отсылались большому количеству людей. Чрезмерная обработка: слишком много редактирований, которые не требовались Недостаточно использованный талант: многие из персонала ИС, анализировали электронные письма статуса и пытались определить, должны ли они что-нибудь делать Дефекты: ошибки при копировании информации | Сокращение передачи выполнения, особенно во время фазы идентификации и утверждения. Сокращение числа тех, кто должен утвердить изменение с пяти до одного. |
| Необходимость в чрезмерном одобрений | Временное решение менеджерами по улучшениям, что им необходимо одобрять изменения. | Чрезмерная обработка: слишком много согласований. Недостаточно использованный талант: слишком много согласований, которые не требуются | Сокращение числа тех, кто должен утвердить изменение с пяти до одного. Путем ответа на вопрос: «Почему тебе необхожимо утверждать это?» |
После этого, группа разработала новый процесс, который фокусировался на первопричинах, определенных на этапе анализа (как показано в таблице). Передачи выполнения и процесс утверждения были сокращены. Разрабатывая решения самостоятельно, менеджеры по улучшениям получили право собственности на процесс, а это очень важно при поиске путей улучшения.
Рисунок 4: Карта правильного процесса
| оригинал | перевод |
| Business request for change (RFC) | Бизнес-запрос на изменение |
| Write RFC and get number | Написание запроса и получение номера |
Rejected | Отклонен |
Send request, notify business partner | Отправка запроса, уведомление бизнес-партнера |
Approved | Утверждение |
UAT approval if required | При необходимость одобрение теста на приемлемость для пользователя |
On email, include business partner | По электронной почте, включают бизнес-партнера |
Review changes monthly and send invoice | Анализ ежемесячных изменений и отсылка счета |
Новый процесс был опробован и были определены новые показатели времени цикла.
Общие результаты
Результаты проекта следующие:
- Сокращение среднего времени цикла – с 20 дней до 10.
- 150 тысяч $ экономии путем устранения деятельности, не добавляющей ценности, четырех сотрудников отдела ИС, также это позволило этим сотрудникам сосредоточиться на более важной работе. Сокращений сотрудников не произошло.
- Улучшения удовлетворенности клиента путем выполнения запроса за 10 дней.
- Ясное понимание процесса для обучения новых сотрудников в случае необходимости
Полученные уроки - При необходимости проведения удаленных /виртуальных семинаров, планирования их с недельным перерывом, позволяет менеджерам по улучшениям собирать информацию и делиться ею между собой.
- Также Черный пояс собирает и распространяет информацию между виртуальными семинарами, что содействует более эффективному их проведению.
- Обязательное наличие двух координаторов семинаров – один для того, чтобы вести группу, а другой для сбора информации / действий
- Участие спонсора является ключевым для установления сильной мотивации и пользы, а также помогает при распределении рабочей нагрузки в команде проекта.
Некоторые дополнительные аспекты для успешного выполнения проекта по непрерывному улучшению включают создание четких планов, с использованием методологии DMAIC, но также эти планы должны быть гибкими, для изменений во время семинаров, привлечении спонсора и экспертов с установлением прозрачных и четких коммуникаций, а также позволение им принимать решение. Так как Черный пояс возглавляет несколько проектов, их уверенность при планировании и выполнении значительно возрастет. |
авторы:
RJ Stretch, Мастер Черного пояса лин 6 Сигм. Опытный лидер по непрерывному улучшению с 22 летним опытом работы в фармацевтической промышленности и отрасли защиты. Ориентируемый на результаты, решительный руководитель с доказанным успехом в совершенствовании процесса, возглавляющий проекты, проводящий семинары по улучшению, объясняющий возможности Лин Шесть Сигм путем развития/обучения персонала методологиям и инструментам Лин Шесть Сигм. Также имеет дополнительный опыт в качестве бизнес-консультанта, менеджера консультанта, архитектора базы данных, администратора базы данных и разработчика программного обеспечения. Успешно сертифицирован Институтом проектного менеджмента и Фондом сертификации в области управления ИТ-услуг (ITIL) как Черный пояс Лин 6 Сигм (LSSBB), и внешний и внутренний AstraZeneca, профессионал проектного менеджмента (PMP).
© Материал подготовлен Анной Джежик
по материалам зарубежных изданий
http://www.klubok.net/
см. также:
