Книга: Руководство по DevOps
Глава 6. Основные сведения о работе в потоке создания ценности, превращении его в прозрачный и расширении на всю организацию
Глава 6. Основные сведения о работе в потоке создания ценности, превращении его в прозрачный и расширении на всю организацию
Определив, в каком потоке создания ценности мы хотим применить принципы и модели DevOps, мы должны получить достаточное представление, как продукт будет доставляться заказчику: какое задание выполняется и кем, какие шаги можно предпринять для оптимизации потока.
В предыдущей главе мы рассказали о проведенных компанией Nordstrom преобразованиях DevOps под руководством Кортни Кисслер и ее группы. В процессе многолетней работы они выяснили: один из наиболее эффективных способов начать улучшение любого потока создания ценности — провести рабочее совещание с основными заинтересованными сторонами и выполнить упражнения по отображению потока создания ценности. Этот процесс описан в данной главе. Он поможет зафиксировать все шаги создания ценности.
Отображение потока создания ценности может привести к ценным и неожиданным открытиям. Кисслер любит пример, когда команда пыталась уменьшить длительность времени обработки заказов, выполнявшихся через систему «офиса косметики». Написанное на языке COBOL приложение для мейнфреймов обеспечивало деятельность менеджеров в отделах красоты и косметики в магазинах компании.
Приложение давало возможность менеджерам регистрировать новых продавцов для линий продуктов, продававшихся в магазинах компании, чтобы можно было отслеживать комиссии от продаж, давать скидки, предоставленные вендором, и т. д.
Кисслер объясняла:
«Я очень хорошо знала это приложение, раньше я занималась поддержкой этой технологической команды. Почти десять лет в ходе каждого ежегодного цикла планирования по программам мы обсуждали, как перенести это приложение с мейнфрейма на другую платформу. Разумеется, как и в большинстве организаций, даже при наличии полной поддержки руководства мы никогда не могли выкроить время.
Моя команда хотела провести отображение потока создания ценности, чтобы определить, действительно ли приложение на COBOL создает проблему, или, возможно, существует более масштабная проблема, и ее нам необходимо выявить. Провели совещание. Собрали всех, кто имел хотя бы какое-то отношение к доставке продукта внутренним клиентам и партнерам по бизнесу, — членов группы обслуживания мейнфрейма, группы общей поддержки и т. д.
Обнаружили, что, когда менеджеры отдела отправляли форму запроса “назначение исполнителя на линию продукции”, а мы запрашивали его табельный номер, им неизвестный, они либо оставляли соответствующее поле пустым, либо вводили в него текст наподобие “я не знаю”. Что еще хуже, для заполнения формы менеджерам надо было идти из складского помещения в офис, где стояли компьютеры. В результате получалась напрасная трата времени, а запрос несколько раз перебрасывался туда-сюда».
В ходе совещания участники провели несколько экспериментов, в том числе исключили поле с номером сотрудника в форме и позволили другому отделу получать информацию с более низкого уровня. Эксперименты, проведенные при помощи менеджеров соответствующего отдела, показали: время обработки запроса сократилось на четыре дня. Группа позднее заменила приложение для ПК приложением для iPad, что дало возможность менеджерам передавать необходимую информацию, не покидая складское помещение, а время обработки было позднее уменьшено до секунд.
Кисслер с гордостью заявляет: «После потрясающих улучшений требования перенести приложение с мейнфрейма прекратились. Кроме того, руководители других направлений отметили этот факт и стали приходить к нам с длинными списками дальнейших экспериментов, которые они хотели бы провести при нашем участии в своих организациях. Каждый член деловых и технологических команд восхищался результатами, поскольку решались реальные проблемы бизнеса, а самое главное, в процессе решения исполнители узнавали нечто новое для себя».
Далее мы опишем следующие этапы: определение команд, необходимых для создания потока ценности для клиентов, формирование карты потока создания ценности, на которой видны все требуемые операции, и использование карты как руководства для команд, демонстрирующего, как лучше и быстрее создавать продукт. Так мы сможем повторить потрясающие результаты, описанные на примере компании Nordstrom.
Оглавление книги
- Определение всех команд, обеспечивающих поток создания ценности
- Формирование карты потока создания ценности: видеть выполняемую работу
- Создание команды преобразований
- Договориться об общей цели
- Продолжать улучшения, планируя на короткие сроки
- Резервируем 20 % времени для реализации требований, не связанных с функциональностью, и для выплаты технического долга
- Практический пример
- Операция InVersion в компании LinkedIn (2011 г.)
- Увеличить прозрачность работы
- Используйте инструменты для закрепления необходимого поведения
- Заключение
- Резервное копирование при работе InterBase в режиме 24x7
- Ничего, кроме правды: поведение потребителей
- Основные параметры ЭЛТ-мониторов
- Роль товарной категории и установление цены
- Основные "рычаги" управления производительностью
- Глава 7 Чего нужно опасаться при моделировании бизнес-процессов. Проектные риски моделирования бизнеспроцессов
- Категорийный менеджмент. Курс управления ассортиментом в рознице
- 1.1. Информатика. Предмет информатики. Основные задачи информатики
- 11 Основные возражения и ответы на них
- 2.5. Разработка технического задания на проведение детального анализа рынка при работе над инновационным проектом. Основ...
- 7.4.2.4. Создание своего первого LiveCD
- Приложение 21 Образец должностной инструкции начальника отдела по работе с сетевыми клиентами