Планирование сроков отдельных задач остановочного ремонта – составление графика
Основной вопрос, на который хочу сегодня ответить, — это "Как же понять сроки своего ремонта?"
В предыдущих постах я указывал, что продолжительность остановочного ремонта определяется его критическим путём (как и у любого проекта).
Напомню, "Критический путь" — это максимально длинная цепочка взаимосвязанных задач проекта, не более.
Часто сталкивался с тем, что многие руководители привносили дополнительные смыслы в это определение: "Самые критично важные работы", "Работы первого приоритета" и далее в таком же духе. И да, критический путь может состоять из "супер-пуппер важных работ", но это не обязательно. Но сегодня не об этом.
Ниже дам несколько рекомендаций о том, как максимально правильно определить сроки вашего ремонта (справедливы в привязке при использовании специализированного ПО, как MS Project или Oracle Primavera).
1. Для правильного определения критического пути нужно правильно увязать между собой задачи ремонта. В посте #2 я давал своё видение основных вех остановочного ремонта. Все эти вехи должны лежать на критическом пути.
2. Все задачи критического пути должны быть связаны между собой только логически, без задержек по времени.
3. Ни одна задача не должна быть привязана к конкретной дате, только режим "автоматическое планирование". Единственным исключением тут может быть веха "A", только её можно "прибить гвоздями к календарю", это поможет оперативно вносить изменения по срокам.
4. Задачи должны быть детализированы до такого уровня, чтобы они могли быть выполнены одной минимальной бригадой исполнителей.
5. И если вы недавно заморочились эффективностью ремонтов, не стоит делать много уровней глубины графика, оптимально 4-5. Как-нибудь потом об этом расскажу подробнее.
И самое главное. Определение продолжительности получившихся элементарных операций. Тут есть несколько источников:
1. Экспертная оценка специалиста, обладающего опытом в выполнении работ в рассматриваемой области.
2. Исторический (зафиксированный) опыт выполнения этой и подобных ей операции, если он, конечно, есть.
3. Норматив времени на эту работу, опять же – если есть.
Продолжительности задач, полученные любым из этих способов, можно использовать в чистом виде.
Я рекомендую их использовать именно с таким приоритетом, в каком порядке они приведены.
Простой пример: нужно запланировать установку стандартной межфланцевой заглушки DN2" CL300. Есть норматив на эту работу – 30 минут. Ранее на этом месте заглушки уже устанавливали, но фактических записей о времени на эту работу никто не вёл – нельзя использовать исторический опыт. Будущий исполнитель этой работы при осмотре определил, что сможет её выполнить за 20 минут. Значит для графика принимаем продолжительность этой операции в 20 минут!
В любом случае, определение продолжительности задач на этом не должно заканчиваться! Во время выполнения ремонта необходимо организовать работу по фиксации фактических сроков. И при планировании сроков ремонта нового цикла эти данные станут источником №2. И так будет реализовываться принцип непрерывных улучшений!
В предыдущих постах я указывал, что продолжительность остановочного ремонта определяется его критическим путём (как и у любого проекта).
Напомню, "Критический путь" — это максимально длинная цепочка взаимосвязанных задач проекта, не более.
Часто сталкивался с тем, что многие руководители привносили дополнительные смыслы в это определение: "Самые критично важные работы", "Работы первого приоритета" и далее в таком же духе. И да, критический путь может состоять из "супер-пуппер важных работ", но это не обязательно. Но сегодня не об этом.
Ниже дам несколько рекомендаций о том, как максимально правильно определить сроки вашего ремонта (справедливы в привязке при использовании специализированного ПО, как MS Project или Oracle Primavera).
1. Для правильного определения критического пути нужно правильно увязать между собой задачи ремонта. В посте #2 я давал своё видение основных вех остановочного ремонта. Все эти вехи должны лежать на критическом пути.
2. Все задачи критического пути должны быть связаны между собой только логически, без задержек по времени.
3. Ни одна задача не должна быть привязана к конкретной дате, только режим "автоматическое планирование". Единственным исключением тут может быть веха "A", только её можно "прибить гвоздями к календарю", это поможет оперативно вносить изменения по срокам.
4. Задачи должны быть детализированы до такого уровня, чтобы они могли быть выполнены одной минимальной бригадой исполнителей.
5. И если вы недавно заморочились эффективностью ремонтов, не стоит делать много уровней глубины графика, оптимально 4-5. Как-нибудь потом об этом расскажу подробнее.
И самое главное. Определение продолжительности получившихся элементарных операций. Тут есть несколько источников:
1. Экспертная оценка специалиста, обладающего опытом в выполнении работ в рассматриваемой области.
2. Исторический (зафиксированный) опыт выполнения этой и подобных ей операции, если он, конечно, есть.
3. Норматив времени на эту работу, опять же – если есть.
Продолжительности задач, полученные любым из этих способов, можно использовать в чистом виде.
Я рекомендую их использовать именно с таким приоритетом, в каком порядке они приведены.
Простой пример: нужно запланировать установку стандартной межфланцевой заглушки DN2" CL300. Есть норматив на эту работу – 30 минут. Ранее на этом месте заглушки уже устанавливали, но фактических записей о времени на эту работу никто не вёл – нельзя использовать исторический опыт. Будущий исполнитель этой работы при осмотре определил, что сможет её выполнить за 20 минут. Значит для графика принимаем продолжительность этой операции в 20 минут!
В любом случае, определение продолжительности задач на этом не должно заканчиваться! Во время выполнения ремонта необходимо организовать работу по фиксации фактических сроков. И при планировании сроков ремонта нового цикла эти данные станут источником №2. И так будет реализовываться принцип непрерывных улучшений!