CC BY
101
тдН
=_-_* (9)
рЧг* * К чгЫ
где - драйвер распределения затрат на себестоимость п-го бизнес-продукта, для однопродуктовой бизнес-задачи = 1.
Таким образом, процессно-продуктовый подход к экономике и управлению предприятием интегрировано с бюджетированием и расчетом себестоимости бизнес-продуктов позволяет определить цены конечных, формирующих прибыль предприятия, и промежуточных бизнес-продуктов, а также распределить прибыль между подразделениями в зависимости от их вклада в создаваемую на предприятии стоимость, что существенно повысит эффективность деятельности предприятия.
Список литературы:
1. Смирнов Ю.Н Процессно-задачный инжиниринг бизнес-процессов и стандарт управления предприятием // Научно-практический журнал «Интеграл». - 2007. - № 5.
2. Смирнов Ю.Н., Сидорова Е.А. Методология процессно-продуктового бюджетирования и расчета себестоимости продукции // Научно-практический журнал «Интеграл». - 2009. - № 6.
3. Механизм распределения части прибыли предприятия между его подразделениями [Электронный ресурс]. - Режим доступа: http://ecopre.ru/ vшtriproizvodstvennye-ehkonomicheskie-otmsheniya/mekhanizm-raspredelem-ya-chasti-pribyli-predpriyatiya-mezhdu-ego-podrazdeleniyami.html (дата обращения: 01.05.2012).
ПРИМЕНЕНИЕ KANBAN МЕТОДА ДЛЯ ВИЗУАЛИЗАЦИИ АДМИНИСТРИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ ОРГАНИЗАЦИИ ПРИ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ ПРОИЗВОДСТВОМ
© Ситникова А.А.*
Санкт-Петербургский государственный политехнический университет,
г. Санкт-Петербург
Зарождение и основные принципы метода КапЬап
Визуализация это средство, с помощью которого мы понимает рабочий процесс, визуализация бизнес-процесса это первый шаг к управлению данным процессом.
* Аспирант кафедры Стратегии развития организации.
Одним из широко известных методов визуализации бизнес-процессов является метод (или система) Kanban, изначально зародившийся в Японии как система управления производством и снабжением.
Слово «Kanban» В переводе с японского языка означает «бирка» или «значок» [1]. Основным достоинством данного метода является возможность видеть изменение системы в режиме реального времени, что позволяет оперативно сообщать о возникновении любых отклонений в ходе процесса. В 1940-1950 гг. система Kanban была разработана Тайити Оно для обеспечения возможности контроля производственных процессов и осуществления принципа «точно вовремя» (Just In Тте) на заводах «Тойота» в Японии. Теоретической основой Kanban являются идеи одного из основоположников научного менеджмента, американского ученого Ф. Тейлора (18561915); основоположника массового производства в автомобильной промышленности Г. Форда (1863-1947), а также некоторые положения философии дзэн-буддизма и конфуцианства.
Очевидно, что оперативная информация лучше, чем запоздалая или ее полное отсутствие. Но есть кое-что более важное, чем информирование, - это решение, какое действие стоит предпринять при обнаружении анормальностей. Согласно объяснению Т. Оно, сделанному в книге «Производственная система Койоты», важно предотвратить повторение ошибки [2, с. 18]
Основные правила системы Kanban:
Правило 1. Для последующих процессов детали поставляются предыдущими процессами.
Правило 2. На предыдущих процессах производится только то, что изъято последующим процессом.
Правило 3. На последующие процессы поступают только бездефектные изделия.
Правило 4. Производство должно быть выровненным.
Правило 5. Все детали сопровождаются Kanban-ами.
Правило 6. Со временем количество Kanban-ов постепенно уменьшается [3, с. 39].
Итак, с помощью доски Kanban был создан мощный визуальный инструмент управления, для распространения интерактивной ментальной модели, изначально представлявший собой систему карточек с указанием полной информации о детали на заводе «Тойота» для отражения динамики процесса производства и поставок.
Уже позднее данную методику было предложено адаптировать для разработки программного обеспечения (ПО). В наши дни этот подход активно используется программистами по всему миру.
Эволюция Kanban в методику разработки программного обеспечения
Методика разработки ПО с использованием Kanban была придумана Дэвидом Андерсеном. Многие из подобных практик и подходов использо-
вались разными Agile1 командами, прежде чем были описаны Дэвидом как единое целое. Нововведения Дэвида состояли в том, что он ясно ограничил задачи находящиеся «в процессе». Это делалось и раньше другими Agile-ко-мандами, но в Kanban существует всем известное ограничение на количество рабочих задач, которые могут выполняться в одно время и этот предел обычно довольно низкий. Множество Agile команд используют белую доску для отслеживания работы во время итерации. Обычно она разделена на три секции: «Сделать», «В процессе» и «Готово». Когда налагается физическое ограничение на задачи «В процессе», то бывает полезным сделать дальнейшее разбиение. Задача «в процессе» может быть: в разработке, в тестировании, в анализе или в других статусах. Каждый из них может иметь свое ограничение на количество одновременных задач. Итак, второе нововведение в Kanban заключается в разделение доски на множество разных колонок. Иногда между ограниченными колонками могут вставляться буферы, которые могут помечаться как «сделано». [5]
В результате анализа случаев применения описанных методик мы сформулировали некоторые рекомендации по внедрению системы Kanban:
1. Начинайте именно с того, что вы делаете сейчас.
Метод Kanban не дает описания ролей или стадий процесса. Нет такого понятия, как Kanban-процесс разработки ПО или проектное управление с помощью Kanban-метода. Метод Kanban начинается с ващей роли и ваших текущих процессов, и стимулирует непрерывные, постепенные и эволюционные изменения всей системы.
2. Визуализируйте поток работ.
Разбейте работу на части, выпишите каждый из пунктов на карточку и прикрепите на стену. Подпишите столбцы, чтобы видеть на какой стадии находится каждое задание.
5. Ограничьте незавершенную работу.
Определите возможное количество незавершенных пунктов на каждой стадии рабочего процесса.
6. Измеряйте время выполнения задачи.
Оптимизируйте процесс, чтобы свести время выполнения задачи к минимуму и сделать его настолько прогнозируемым, насколько это возможно [4, 5].
Kanban-методика, примененная для разработки ПО, позволяет руководителю команды четко отслеживать прогресс по проекту в режиме реального времени, фиксировать и предотращать отклонения, при этом все участники команды чувствуют себя максимально вовлеченными в процесс разработки, что способствует не только оптимизации процесса, но и формированию командного духа.
1 Гибкая методология разработки (англ. Agile software development, agile-методы) - серия подходов к разработке ПО, представляющая собой методологию творческого процесса, пред-пологающую наибольшую гибкость и применение высокого уровня прагматизма к поставке готовой продукции [4].
Перенос опыта внедрения методики Kanban для разработки ПО на другие бизнес-процессы
Успешность переноса методики Kanban, изначально придуманной для управления производственным процессом, к разработке ПО, в первую очередь, доказывает широту применимости данного метода. Особую ценность методики дал перенос обычной белой доски с разноцветными карточками, использовавшейся в любом офисе командами разработчиков, из территориально - ограниченного пространства (офиса) в информационное (он-лайн доступ через браузер, например), выполненное нашей рабочей группой.
Дальнейшее развитие методики Kanban мы видим в использовании ее технологий для любых задач бизнеса, от личного планирования одного сотрудника до совместной работы над крупными бизнес-процессами.
Рассмотрим доску Kanban в действии (Пример 1).
Доска, представленная в стандартном исполнении на рис. 1, разделяется на 5 колонок:
- Backlog - запас задач или отставание по задачам (то есть задачи к распределению по доске, которые уже сформулированы, но еще не формализированы);
- To do - задачи, которые необходимо выполнить;
- Do today - задачи, которые необходимо выполнить сегодня;
- In progress - задачи, над которыми вы работаете в данный момент;
- Done - выполненные задачи.
Davflou'Weekfloiv personal board
То do Da статья now today In progress Done
Backlog
филосс экзамен
Рис. 1. Пример доски Kanban
Один из принципов заполнения доски карточками - одна задача на одной карточке. Основываясь на принципе «человек может сделать хорошо только одно дело одновременно» берем одну задачу из столбца «to do today» и переносим в столбец «in progress» в тот момент, когда начинаем выполне-
ние данной задачи. Перенесение задачи в столбец «done» произойдет в тот момент, когда мы закончим выполнение этой задачи.
Нами был реализован перенос доски в он-лайн пространство с возможностью многопользовательского доступа, что позволило наблюдать за прогрессом по поставленным задачам, отслеживать любые нестабильные ситуации и предотвращать их в будущем.
Рассмотрим усложненный пример доски (Пример 2) для применения к процессу поиска новых сотрудников (рис. 2). Данный процесс подходит под все критерии методологии Kanban ПО (он ограничен по времени, его можно разбить на части и т.д.), соответственно, как нельзя лучше может быть визуализирован с помощью Kanban-доски. А многопользовательский доступ к доске позволит нескольким членам команды работать над задачами одновременно. Итак, в первый столбец «Backlog» вписываются все поступившие в обработку резюме (отклики на размещенные вакансии или найденные HR-специалистом команды), следуя правилу одна задача - одна карточка, в данном случае один кандидат - одна карточка. Столбцы подобраны таким образом, что бы максимально визуализировать часть процесса отбора кандидата. Передвигая карточку с именем кандидата по пути «источник прихода кандидата - полнота информации о кандидате - первичный скрининг кандидата и т.д.» мы получаем представление, как о пройденных этапах, так и последующих.
Рис. 2. КапЬап-доска «Поиск новых сотрудников» Процесс получается предельно прозрачным и объективно описанным.
Для оценки и оптимизации временных затрат на процесс нами была реализована фунция фиксирования времени передвижения карточки по доске. На рисунке 2. виден путь одной из карточек с затраченными на каждое из передвижений временными затратами. Из графа видно, что прошла 1 минута (1m) с момента поступления резюме в обработку до передачи резюме на скрининг специалисту Олегу, который через 2 минуты принял решение о назначении Skype-интервью с кандидатом.
На основании успешного переноса Kanban-методики разработки ПО на бизнес-процесс «подбор сотрудников» можно судить о применимости метода Kanban для различных бизнес-процессов. Целесообразно в ближайшее время расширить применение метода для решения спектра задач для проектов с большим количеством участников.
Список литературы:
1. Марчвински Ч., Шук Д. Иллюстрированный глоссарий по бережливому производству. - М.: Альпина Бизнес Букс : CBSD, Центр развития деловых навыков, 2005.
2. Shigeo Shingo. A Study of the Toyota Production System. - Productivity Press, 1989.
3. Попеско И. Kanban для рабочих: пер. с англ. / Под ред. В. Болтруке-вича. - Издательство: Институт комплексных стратегических исследований, 2007. - (Серия: Производство без потерь).
4. Rouse Margaret. Agile software development (ASD) [Электронный ресурс]. - Режим доступа: http://searchsoftwarequality.techtarget.com.
5. Kelly Allan. 10 things to know about Kanban software development [Электронный ресурс]. - Режим доступа: http://allankelly.blogspot.com.
6. Anderson D. Kanban. - Blue Hole Press, 2010.
7. Хенрик Книберг и Маттиас Скарин. Kanban и Scrum: выжимаем максимум. - C4Media, 2010.
ОСОБЕННОСТИ ДИВЕРСИФИКАЦИИ В ИНВЕСТИЦИОННО-СТРОИТЕЛЬНЫХ КОМПАНИЯХ
© Федяев М.В.*
Научно-производственное объединение «Мостовик», г. Омск
Диверсификация в инвестиционно-строительных компаниях является связанной и синергетической, базируется на распределении капита-
* Заместитель генерального директора, соискатель кафедры «Инновационного и проектного управления» ОмГУ им. Ф.М. Достоевского.
