Спасибо, примерно так и реализовали. Взяли условно нулевую точку и от неё нарастающим итогом рассчитали календарное и рабочее время для всего календаря. Единовременно. Для удобства и решения иных запросов сделали хранение накопленных значений на начало и на конец каждой даты. Далее уже все проще становится - по заданной дате находим её накопленное рабочее время, определяем по продолжительности искомое накопительное значение. Ищем дату где впервые достигается или превышается пороговое значение и уже точно рассчитываем момент времени возникновения "просрочки". В общем, сделали в виде функции на MS SQL, спрятав логику внутрь её. Результат и скорость работы на наших объёмах полностью устраивают, а фуннкия дала гибкость - возможность использовать в различных местах, в зависимости о им контекста и не усложняячего логику.
Инструмент в теории звучит красиво и интересно. Однако из моей практике он ни разу нам не пригодился... (про RACI марицу знали и понимали, как она работает). У нас реализовано много проектов небольших с очень коротким циклом Time2Market (от 2 недель до 2-х месяцев) Для каждого из них прописывать RACI - себе дороже (время - самый ценный ресурс), лучше это время посвятить развитию проекту(ам).
На проекте с сроком вывода в ОПЭ в 9 месяцев он тоже не зашел... Своего заказачика мы знали очень хорошо, как и он нас - наверное, это и помогло - на старте проекта договорились о "правилах игры" и никакого RACI нам делать не пришлось - все "неожиданные" вопросы решалось оперативно и в режиме онлайн.
Возможно, в RACI есть смысл на очень больших, длительных проектах и с высоким фактором неопределености (хотя бы в начальных его фазах).
Так что ограничения для применения инструмента есть, но за статью спасибо - подано интересно!
Статья интересная и очень близка по характеру работы моей команды, за нее респект. Отмечу, что такие подходы можно применять в рамках достаточно крупного подразделения, состоящих из более мелких и состоящих в связях и взаимоотношениях друг с другом (мини-организация), где как раз мы и "рефакторим"
Практика показывает, что для изменения (или создания) живых бизнес-процессов должно сойтись много звезд на небе — как минимум некотрое количество образованных, и одновременно неравнодушных людей, плюс внешний фактор который заставляет искать изменений. И нет, процесс нельзя принести с улицы, вычитать в книжке — и внедрить как прокрустово ложе. То есть можно — но что-то в фирме при этом отвалится. Процессы надо вырастить.
В нашем случае именно такая "гремучая смесь" и поиск своего пути позволила запустить процессы качественных изменений и добиться существенных результатов.
Управлять ограниченими (фокусируя их там где это требует момент времени для оптимального анализа, управления и изменения) - учимся и это достаточно интересно. И уж точно, это на стыках как инженерных так и бизнес компетенций
Спасибо за статью, сэкономила много времени. Решал похожую задачу, как раз склонялся к тому, чтобы использовать интервалы, ну а здесь уже все разжевано. Так что применил для своих целей. Мы используем MS SQL, но это скорее частности, идеи, принципы и подходы общие
В развитии темы - если стоит посмотреть "в будущее", а не о анализировать прошлое (состоявшийся факт). Есть запись с дампом поступления (обращения\запрос, да что угодно) и нужно в своответствии с SLA рассчитать максимальный срок обработки обращения. Например, обращение должно быть рассмотрено и обработена не позднее 24 рабочих часов с момента поступления. Как расчитать "дедлайн" - момент, с которого начнется просрочка (т.е. до какого момента должен времени быть обработан документ). Решение для себя нашел, оно также на принципах интервалов, но не такое изящное, как описано в статье, если решать задачу "с конца". Поэтому если есть советы, как стоит подойти к решению такой задачи, буду признателен.
Спасибо за добрые слова. Уверен, что с аналогичными вызовами сталкивались гораздо больше компаний и удивлены, что информации об подходах, способах решений в рамках профессионального IT обсуждения крайне мало. Тематические ресурсы\конференции ОЦО отвечают на другие вопросы, там достаточно много элементов пиара, но мало реальной практики. Поэтому мы решили попробовать рассказать о своем опыте, своих способах, находках и решениях. Также есть интерес услышать об опыте других и услышать конструктивную критику и предложения
Нам есть еще много чем поделиться, это в будущих выпусках
Спасибо, примерно так и реализовали. Взяли условно нулевую точку и от неё нарастающим итогом рассчитали календарное и рабочее время для всего календаря. Единовременно. Для удобства и решения иных запросов сделали хранение накопленных значений на начало и на конец каждой даты. Далее уже все проще становится - по заданной дате находим её накопленное рабочее время, определяем по продолжительности искомое накопительное значение. Ищем дату где впервые достигается или превышается пороговое значение и уже точно рассчитываем момент времени возникновения "просрочки". В общем, сделали в виде функции на MS SQL, спрятав логику внутрь её. Результат и скорость работы на наших объёмах полностью устраивают, а фуннкия дала гибкость - возможность использовать в различных местах, в зависимости о им контекста и не усложняячего логику.
Инструмент в теории звучит красиво и интересно. Однако из моей практике он ни разу нам не пригодился... (про RACI марицу знали и понимали, как она работает). У нас реализовано много проектов небольших с очень коротким циклом Time2Market (от 2 недель до 2-х месяцев) Для каждого из них прописывать RACI - себе дороже (время - самый ценный ресурс), лучше это время посвятить развитию проекту(ам).
На проекте с сроком вывода в ОПЭ в 9 месяцев он тоже не зашел... Своего заказачика мы знали очень хорошо, как и он нас - наверное, это и помогло - на старте проекта договорились о "правилах игры" и никакого RACI нам делать не пришлось - все "неожиданные" вопросы решалось оперативно и в режиме онлайн.
Возможно, в RACI есть смысл на очень больших, длительных проектах и с высоким фактором неопределености (хотя бы в начальных его фазах).
Так что ограничения для применения инструмента есть, но за статью спасибо - подано интересно!
Статья интересная и очень близка по характеру работы моей команды, за нее респект. Отмечу, что такие подходы можно применять в рамках достаточно крупного подразделения, состоящих из более мелких и состоящих в связях и взаимоотношениях друг с другом (мини-организация), где как раз мы и "рефакторим"
Cоглашусь с комментариями @ruomsergвыше:
В нашем случае именно такая "гремучая смесь" и поиск своего пути позволила запустить процессы качественных изменений и добиться существенных результатов.
Управлять ограниченими (фокусируя их там где это требует момент времени для оптимального анализа, управления и изменения) - учимся и это достаточно интересно. И уж точно, это на стыках как инженерных так и бизнес компетенций
Спасибо за статью, сэкономила много времени. Решал похожую задачу, как раз склонялся к тому, чтобы использовать интервалы, ну а здесь уже все разжевано. Так что применил для своих целей. Мы используем MS SQL, но это скорее частности, идеи, принципы и подходы общие
В развитии темы - если стоит посмотреть "в будущее", а не о анализировать прошлое (состоявшийся факт). Есть запись с дампом поступления (обращения\запрос, да что угодно) и нужно в своответствии с SLA рассчитать максимальный срок обработки обращения. Например, обращение должно быть рассмотрено и обработена не позднее 24 рабочих часов с момента поступления. Как расчитать "дедлайн" - момент, с которого начнется просрочка (т.е. до какого момента должен времени быть обработан документ). Решение для себя нашел, оно также на принципах интервалов, но не такое изящное, как описано в статье, если решать задачу "с конца". Поэтому если есть советы, как стоит подойти к решению такой задачи, буду признателен.
Спасибо за добрые слова. Уверен, что с аналогичными вызовами сталкивались гораздо больше компаний и удивлены, что информации об подходах, способах решений в рамках профессионального IT обсуждения крайне мало. Тематические ресурсы\конференции ОЦО отвечают на другие вопросы, там достаточно много элементов пиара, но мало реальной практики. Поэтому мы решили попробовать рассказать о своем опыте, своих способах, находках и решениях. Также есть интерес услышать об опыте других и услышать конструктивную критику и предложения
Нам есть еще много чем поделиться, это в будущих выпусках