Обсуждение
Читать и комментировать в ЖЖ ↗
И у проектников и процессников есть одна дыра, с которой всерьез не берутся разбираться.
Возмем в терминах ресурсов. Есть такая хрень, как сбалансированное сочетание компетенции с компетентностью. Ее можно иногда считать ресурсом. Проблем в измерении. Массса проблем когда этого сочетания нет на ключевых позициях - неважно в проекте или в процессе.
Когда от этой проблемы убегают закрывая на нее глаза, получаются или провальные проекты или выхолощенные функциональные организации (выхолощенные, значит кастрированные, не способные отвечать на непредусмотренные вводные).
Комментарий
Интересно, что попытка внедрить этот опыт на нашем "заводе" путём привлечения людей из сочинского оргкомитета не привела к существенным изменениям технологий разработки и управления, коснувшись только самого верхнего слоя управленцев.
Комментарий
А софтом этот опыт пробовали у вас поддержать? Там же уникальный софт был сделан.
Насчёт же "верхнего слоя управленцев" история очень похожая на попытки сработать с идеями Голдратта -- многие рассказывают такие же истории: верхние управленцы принимают на вооружение, а внизу всё вязнет.
Комментарий
а где почитать про case management? гугль откликается нерелевантно
Комментарий
http://ailev.livejournal.com/1092118.html
http://ailev.livejournal.com/946134.html
http://en.wikipedia.org/wiki/Advanced_case_management (ранее было Adaptive, конкуренция)
Ru.wiki Адаптивное управление кейсами
Комментарий
Ссылкой на описание этого софта поделитесь?
Комментарий
Лаконичненько! Я ожидала длинной телеги о тонкостях различий и их следствиях. Ребята отличные, рефлексия у них на многих уровнях, это непривычно было видеть. Но я все пытаюсь представить, как выглядела бы та же история при ограниченности ресурсов/бюджетов и жесткой необходимости вводить третье измерение с их распределением между точками.
Комментарий
а-а-а. и еще. у них был вот такой чудесный слайд 21. возможно, ты его не запомнил. как раз про разделение проектов и процессов. посмотри на горбатую диаграмму - с момента минус 20 месяцев, с начала "веньюизации", у них спадает число проектов и нарастает число процессов - то есть у них была четкая рефлексия и на эту тему.
Изображение — открыть источник
Комментарий
(гребаный жж, я прошу прощения, что пришлось отредактировать сто раз, чтоб показать картинку)
Комментарий
Каменный век управленческой науки никак не сменится бронзовым.
Все так же обсуждают разные кейсы загонов мамонтов то(л)пами и дубинами.
Комментарий
Софт был НАПИСАН с нуля для этого одного "суперпроекта", вряд ли его где вообще описывали. Про сам софт был один слайд (он ваялся поверх платформ Майкрософта).
Комментарий
Там всё время говорилось про ограниченность ресурсов. Бюджеты уторговывались, как водится, персональными распоряжениями, мимо софта. Софт просто фиксировал эти бюджеты, не более.
Комментарий
Я вообще удивлён наличием картинки, чего ж извиняться )))
Я слайд запомнил, но там к нему много вопросов: у процессов там ведь тоже контрольные точки -- это означает, что процессы, кейсы и проекты наравне с поручениями отрабатывались как кейсы. Ибо SLA нужно контролировать время от времени (например, "нет нарушений SLA на момент окончания игр", прохождение этих точек контроля и есть "кейсы" -- равно как сами стройки кейсы, а проектный они или процессный характер выносится за пределы системы прохождения кейсов).
Комментарий
Только маленькая разница: отконтролировано 15тыс. кейсов. Часть кейсов безумная, но мы содержание их не смотрим, смотрим как раз менеджерскую технику. 15тыс. кейсов (типа "построить стадион") всё-таки не очень похожи на загон мамонтов.
Комментарий
Что-то совсем не понятно, как этот слайд совмещается с увиденным Анатолием кейс-менеджиентом. А воотюще этп презентация где-то доступна? Или всё равно кейс-менеджмент можно было только распознать при прослушивании их рассказа, а в презентации этого не увидеть?
Комментарий
В презентации вообще ничего не увидеть. И в прослушивании тоже нужно выдирать кусочки из разных мест, чтобы понять происходящее. Ибо терминология ни разу не кейсовая, вообще.
Комментарий
Наверное пора уже строить системы, интегрирующие проектные, процессные и кейс-ориентированные методы управления.
Интегрированные, во-первых, на уровне архитектуры - там вообще правильнее говорить о способностях (capability), а процесс это или проект - "детали реализации".
Во-вторых, на уровне сквозного управления ресурсами (workload и т.п.)
В-третьих, на уровне платформы и, в частности, социальной функциональности. Все говорят о социалке, но кому нужна социальная функциональность, реализованная отдельно в BPM, PM и ACM - системе? Три соцсети в одной компании - явный бред.
Во вторник рассказываем обо всем этом на конференции в Штатах: http://www.bpmnext.com/2015-schedule/ Посмотрим на реакцию процессных гуру.
Комментарий
Увы, парадигмы вымирают только с их носителями. Я бы только поддержал ваши тезисы (более того, современные системы управления задачами, как они стали называться, уже потихоньку кушают и процессные и проектные системы. То есть "надо строить системы" -- по мере понимания проблемы, люди строят такие системы, инвесторы рискуют и финансируют такой софт. Но его мало, он плохо известен, и пока молод -- плохо поддерживает функциональность проектных систем, не всегда в нём настраиваемы процессы и т.д.. Болезни переходного возраста).
Комментарий
Про управление задачами не соглашусь - они уж очень lightweight.
Вымирание можно ускорить ;) Весь вопрос в востребованности, т.е. в новых идеях: 1) есть ли они? 2) достаточно ли они привлекательны, чтобы породить значимый спрос, который оправдает инвестиции в разработку?
Просто идеей очередной интеграции всего со всех людей прожженых вряд ли увлечешь. А вот идеей интеграции на уровне корпоративной архитектуры и идеей интеграции на уровне социального взаимодействия - надеюсь, что да.
И "надо строить" - это фигура речи такая, вообще-то мы везем на конференцию живую демонстрацию продукта. Ну хорошо - пока не на 100% продукта, но живую.
Комментарий
С продуктом это правильный подход! Я ровно про это и писал: говорить про это менее эффективно, чем сделать и показать. А дальше предпринимательский риск, как водится.
Про управление задачами, тут дилемма инноватора: все прорывы начинаются с "плохих низкокачественных решений", типа первых цифровых фотоаппаратов. А потом поздно пить боржоми, когда рынок отвалился.