Совет №5. Начинайте строить фундамент.
Как вы помните, ранее, я говорил что любая компания состоит из ПэРов — Продуктов, Проектов, Процессов, с возможностью углубления и рассмотрения дополнительно Профессионалов, Практик и Правил, но мы углубляться так далеко не будем. По моему мнению ИТ компании можно условно разделить на следующие направления, с соответствующим весом ПэРа в деятельности компании:
- Кодеры — компании, которые работают по принципу, проект сдал — проект начал. ПР соотношение: Продукты:25%, Проекты: 60%, Процессы:15%
- Разработчики — компании, которые работают разрабатывают проекты, затем какое то время их поддерживают. ПР соотношение: Продукты:25%, Проекты: 40%, Процессы:35%
- Сопровожденцы — компании, которые работают по сопровождению различных ИТ систем. ПР соотношение: Продукты:25%, Проекты: 20%, Процессы:55%
Каждый из данных блоков, по-моему мнению должен быть достаточно плотно зарегламентирован, в качестве основы можно использовать следующие общепризнанные методики:
- Продукты: элементы ITIL. Для документирования выпуска продуктов, можно взять ИТИЛ за основу, и описать как вы будете готовить и запускать ваши продукты, которые будут получены в результате процессов и проектов. Продукты помогут вам четко характеризовать, что вы выдаете клиентам, в качестве результата вашей операционной и проектной деятельности. При этом я бы не советовал строго следовать ИТИЛ, а использовать его опыт как основу для составления собственной документации.
- Процессы: элементы BPMN. В нашей компании процессы являются краеугольным камнем, от которых пляшет коммерческий офис, так как у нас достаточно много продуктов на поддержке. В процессах необходимо четко описывать как процесс начинается, что в него входит, кто владеет и участвует в процессе, что процесс дает на выходе. Также, что делать если что-то пошло не так. При этом я бы не советовал строго следовать БПМН, а использовать его опыт как основу для составления собственной документации.
- Проекты: элементы PMBOK от PMI. Проекты это основа для создания новых продуктов, услуг. Поэтому крайне важно четко выстроить логику работы проектных команд, их взаимодействия с функциональными подразделениями, управление сроками, бюджетами. PMBOK слишком обширен для нас, так что мы берем только его часть и делаем собственный стандарт для работы с проектами. Самый важный момент нужно помнить что проект всегда ограничен по срокам и всегда нацелен на результат, нельзя путать проекты с процессами.
Вывод для руководителя
Подготовьтесь к написанию большого количества документации. Я предлагаю начать с Процессов, затем перейти к Проектам и закончить Продуктами. В следующих постах я начну рассказывать про каждый раздел. И начнем мы с Библиотеки процессов.
Комментарии (4)
undry
02.09.2015 13:55Я бы подошел немного по-другому, в одной статье я нарисовал Цикл Продукты-Проекты-Процессы, это всегда одна компания. В этот цикл со стороны могут прийти входящие ресурсы, ресурсы могут быть разными, но они всегда остаются внешними к компании. Любой ресурс это уголь, который можно бросить в топку цикла ПэРов и который нет необходимости производить самому.
Грубо говоря следующая цепочка ПэРы-->Ресурс-->ПэРы.
mr2dark
02.09.2015 14:26Надо смотреть на это с высоты птичьего полёта. Заказчик, несмотря на то, что с вашей стороны он играет роль в ваших процессах, со своей стороны он в них не участвует, а просто пользуется вашими продуктами (или сервисами) через согласованные интерфейсы. Для него ресурс — это всегда ваш продукт. Ваш процесс, как ресурс он не распознаёт.
Я всё-таки рекомендую использовать такой расклад, так как он сочетается с предметными областями ITIL и TOGAF, выверенными годами и большим количеством людей, а не ломает их.undry
04.09.2015 07:47Как говорится, каждому свое. Мне кажется проще смотреть на компанию, которая получает и производит ресурсы, но у вас конечно, может быть собственное мнение.
mr2dark
Ну вот серии наших статей на пятых частях и пересеклись :-)
Я как раз в своей серии статей и пытаюсь устранить путаницу, которая происходит из-за подобных упрощений.
Нет универсальной системы координат, всегда нужно понимать, какая компания/организационная единица в центре системы координат, когда упоминаются ПэРы.
Вы в третьей части пишете:
В принципе нормальные не мудрёные определения.
Но в реальности есть продукты, проекты и процессы вашей компании, и есть продукты, проекты и процессы заказчика. (Более того, цепочки реальных коммерческих взаимоотношений в B2B настолько сложны, что бывает необходимо ещё и распознавать ПэРы ваших субподрядчиков и ПэРы конечного потребителя).
На самом деле, всё, что вы делаете не для себя, это в вашей терминологии должно называться продуктами вашей компании. И продукты вашей компании будут использоваться в продуктах, проектах и процессах заказчика.
Соответственно, то распределение, которое вы привели для обозначенных условных групп, это распределение продуктов вашей компании в ПэРах заказчика.
В общем от меня есть пожелание всегда приписывать название организации к ПэРам. Тогда у людей картина будет складываться гораздо чётче.
В остальном, очень хорошее начинание. Поддерживаю.