Почему инциденты – это полезно, и как их правильно готовить

Публикация № 535435

Методология - Управление проектом

29
В статье речь пойдет про инциденты в несколько более широком смысле, чем это описано в ITIL – там все-таки в основном рассматриваются те инциденты, которые возникают при работе службы IT, а я расскажу про инциденты в целом, возникающие в процессе деятельности любой организации. Инцидент – это по определению не очень хорошее слово. Если произошел инцидент, значит, произошло что-то плохое, что-то пошло не так, произошел какой-то сбой. Но это – только одна сторона вопроса, а я хочу вам предложить взглянуть на инциденты под другим углом, чтобы понять, чем они могут быть полезны.

Что такое инцидент? Как взаимосвязаны изменения и инциденты?

Для начала давайте разберемся в том, что же такое инцидент.

  • Если переводить с латыни буквально, слово incidens – это «падающий». Это вполне актуально для IT– периодически «падает» софт, «падают» сервера.
  • Если обратиться к толковому словарю Ушакова, то инцидент – это недоразумение, неприятное происшествие.
  • А мы для себя сформулировали такое определение:
    «Инцидент – это любой сбой в нормальном течении процесса» - вообще любой сбой.
  • И одновременно с этим инцидент – это немаловажный источник знаний о несовершенстве процесса, то, что позволяет нам понять, что что-то пошло не так, увидеть проблему (узнать о ее существовании) и попытаться ее решить.

Из понятия инцидента логичным образом вытекает понятие изменений, потому что если инцидент произошел, значит, что-то нужно поменять.

Что такое изменения?

  • Это любые действия, направленные на преобразование технологии, конструкции, инфраструктуры или порядка выполнения любых видов работ.
  • Изменения в любом случае необходимы. Если ничего не менять – это прямой путь «в никуда», к завершению, к закрытию бизнеса – нельзя оставаться на одном месте. Мир вокруг нас меняется, конкуренты не спят, нужно всегда двигаться вперед, нужно постоянно меняться.
  • Но одновременно с этим любое изменение – это источник инцидентов, потому что что-то начинает делаться не так, как раньше.

Для того, чтобы изменения не стали источником проблем, процессом изменений нужно управлять. Естественно, мы можем управлять только теми изменениями, которые происходят внутри нашей компании, но в любом случае управление изменениями обязательно должно быть частью процесса управления инцидентами.

Процесс управления инцидентами

Вообще само по себе управление инцидентами не является каким-то «ноу-хау» – чем-то таким новым, чего раньше никто не делал. Все, кто внедрял у себя ISO9001 (та самая система менеджмента качества), знают, что один из обязательных процессов, который должен быть задействован – это процесс «Корректирующие и предупреждающие действия» – об этом процессе в стандарте ISO9001 достаточно хорошо и подробно описано.

И я расскажу о том, каким образом этот процесс запускался у нас, в нашей реально работающей большой организации: с какими проблемами мы столкнулись, как мы их решали, и какие подходы были найдены. Надеюсь, это будет полезно.

На слайде показано, как выглядит логическая схема процесса по управлению инцидентами: регистрация, купирование, расследование, разработка корректирующих мероприятий и т.д. – это та последовательность шагов, которая должна быть выполнена для того, чтобы была пройдена одна итерация процесса.

Сейчас мы более подробно рассмотрим, что представляетсобой каждый из этих шагов, и какие у них есть ключевые особенности, на которые нужно обращать внимание. Я также расскажу, с какими проблемами мы столкнулись при работе с инцидентами и что вообще с этим делать. И, в завершение, мы попытаемся разобраться, какие есть инструменты, позволяющие сделать управление инцидентами проще, лучше, понятнее.

Итак, мы для себя полностью автоматизировали управление инцидентами на платформе 1С в самописной конфигурации, написанной с нуля.

Карта маршрута получившегося бизнес-процесса показана на слайде – она полностью соответствует описанной ранее логической схеме, но несколько сложнее.

Почему мы выбрали именно такую реализацию для процесса? На самом деле – это частности, потому что не так важно, каким образом процесс работает: он может вестись на бумаге, в Excel, на корпоративном портале, в 1С, на любой другой системе – главное, чтобы процесс работал. Просто когда все данные находятся в автоматизированной системе – это удобно.

Регистрация и купирование инцидентов

По поводу регистрации инцидентов.

Первое (и самое сложное), с чего нужно начать,  – это начать регистрировать инциденты.

Оказывается, убедить людей  в том, что они должны это делать, иногда бывает очень сложно. Почему это проблема? Потому что для того, чтобы зарегистрировать инцидент – встать и сказать, что «у меня произошел сбой» – нужно признать, что инцидент произошел, что был сбой в работе процесса. А поскольку у многих людей в голове существует стереотип, что сбои происходят из-за плохой работы, и если бы они работали хорошо, то сбоя бы не было, то им достаточно сложно признать факт того, что в их зоне ответственности что-то пошло не так.

Следовательно, нужно прививать культуру регистрации инцидентов: у сотрудников должен быть рефлекс " инцидент произошел -> его нужно зарегистрировать".

С чем мы столкнулись? Оказалось, что инциденты, произошедшие в смежных подразделениях, люди регистрировали достаточно охотно, потому что «это не я виноват, это они накосячили», а инциденты, произошедшие в зоне своей ответственности, регистрировать не хотели, потому что для этого нужно было признать что есть проблема. Вместо этого сотрудники пытались как-то спрятать инцидент, "не выносить сор из избы" и пр.

Каким образом мы с этим боролись?

  • Здесь важный момент – для того, чтобы процесс работал хорошо, качественно – инциденты должны регистрироваться на всех уровнях – не только на уровне высшего руководства (генерального, функционального директоров, линейных руководителей). Процесс заработает по-настоящему хорошо только тогда, когда инциденты будут регистрировать все, вплоть до рядовых сотрудников.
  • Во-вторых, должны быть созданы списки значимых инцидентов для каждой должности подразделения – это те инциденты, которые подлежат обязательной регистрации – хочешь ты или не хочешь, их нужно регистрировать.
    Что это может быть?
    Инцидент может иметь общий характер. Например, промышленная компания выпускает какой-то серийный продукт, и по результатам его приемо-сдаточных испытаний в произведенной серии продукции выявляется массовый брак. Это всегда инцидент. Причем, в зависимости от масштаба проблемы один и тот же инцидент может быть транслирован на разные уровни:
    •  Например, выявление массового брака в серийно производимой продукции свыше 3% – это инцидент уровня генерального директора, который требует полной остановки конвейера, полноценного расследования и выяснения причин.
    • А тот же самый инцидент, но с процентом брака более 1%, но менее 3 %– уже относится к уровню директора по качеству или начальника ОТК (то есть, генеральный здесь еще не подключается). Инцидент такого уровня в целом будет возникать чаще, чем на уровне генерального.
    • А инцидент уровня конкретного контролера ОТК – это, например, выявление более 10 приборов в партии или более 3 приборов подряд.

Здесь суть не в конкретных цифрах, а в самом подходе – инцидент может быть одного плана, но в зависимости от тяжести его последствий его нужно рассматривать на разных уровнях. И если на самом нижнем уровне (уровне простого персонала) он может быть просто купирован, то на верхнем уровне он обязательно должен быть расследован, потому что если инцидент дошел до такого уровня, значит проблема есть и она носит системный характер. И если не найти её причину инцидент будет повторяться вновь и вновь.
Списки инцидентов должны быть у всех руководителей – от уровня генерального директора до линейных руководителей и начальников отделов.

  • У каждой зоны ответственности должны быть свои списки инцидентов:
    • Для IT туда может входить, например, сбой в работе серверного оборудования или недоступность информационной системы.
    • Для уровня директора по IT – недоступность информационной системы более одного часа в рабочее время.
    • Для начальника отдела сисадминов это может быть вообще любой сбой в работе оборудования, даже если этот сбой не привел ни к каким проблемам для бизнеса (даже если, например, просто не отработал регламент резервного копирования в ночное время). Выяснять причины нестабильности работы оборудования необходимо в любых случаях, поэтому инцидентом этой зоны ответственности должно быть любое отклонение.
  • В первую очередь в эти списки нужно вносить те инциденты, которые имеют наиболее серьезные последствия для бизнеса – с этогонужно начать. Конечно, пока люди сами к этому еще не готовы, им необходимо дать толчок, каким-то образом их заставить – ввести специальный регламент для регистрации инцидентов. А когда процесс пойдет, это давление можно ослабить.
  • Значимые инциденты регистрируются абсолютно всегда. Лучше, если система учета инцидентов автоматизирована и связана с системами оперативного управленческого учета, потому что тогда можно будет настроить какие-то триггеры, какие-то события, по которым регистрация будет происходить полностью автоматически.
  • Следующий момент – купирование инцидента. После того, как инцидент зарегистрирован, его нужно купировать. Здесь все просто: если произошел пожар – его нужно потушить. Если остановился конвейер – его нужно запустить. Все остальное нужно отложить «на потом».
    Поэтому первое, что мы должны сделать, – это устранить сам инцидент и его непосредственную причину, затем необходимо восстановить нормальное течение процесса, а сразу после того, как течение процесса восстановлено, нужно приступить к расследованию инцидента.

У нас в системе форма регистрации инцидента выглядит так, как показано выше.

Расследование инцидентов

Теперь о том, что касается расследования инцидента.

Все инциденты, входящие в список значимых, расследуются в обязательном порядке. Это расследование заключается в выявлении причины появления инцидента: пытаемся разобраться, какие наши действия привели к тому, что этот инцидент произошел.

Здесь хочу отметить важный момент – проблему, с которой мы столкнулись в процессе своей работы: мы вроде добились того, что люди начали регистрировать у себя инциденты и начали их расследовать, но делали они это только внутри своего центра ответственности. То есть, когда произошел какой-то сбой, начальник отдела позвал ответственного за это сотрудника, они там десять минут посидели, какую-то бумажку написали – все, расследование закончилось.

Так нельзя, это не будет работать – нужно обязательно создать рабочую группу, в которую будут входить сотрудники из разных подразделений:

  • Там обязательно должен быть сотрудник поставщика услуги;
  • Там должен быть сотрудник потребителя услуги, по которой произошел сбой;
  • И, по необходимости, туда можно приглашать еще и экспертов, которые смогут разъяснить какие-то технические детали.

Количество людей в такой группе должно быть 5-6 человек – больше не нужно, иначе эффективность начнет падать.

К расследованию нужно приступить сразу после возникновения инцидента. Чем раньше мы это сделаем, тем выше вероятность, что расследование будет проведено качественно, и мы правильно определим причины, потому что особенность человеческой памяти – все имеет свойство забываться. Поэтому в течение первой недели расследования рабочая группа должна собираться как минимум два-три раза в неделю – это позволит эффективнее расследовать инцидент «по свежим следам». И желательно, чтобы это расследование было завершено в срок не более 10 дней.

Инструменты для расследования инцидентов

Какие есть инструменты для выявления причин инцидентов?

Инструментов, в принципе, достаточно много. Но я вам расскажу про те, которые показали эффективность по нашему опыту внедрения. Это:

  • Инструмент «Пять почему»
  • Диаграмма Исикавы
  • И принцип Парето

Про каждый из них - чуть подробнее.

5 «почему»

Что такое «5 почему»?

Если задать вопрос «Почему» несколько раз подряд, каждый раз спрашивая про предыдущий ответ, мы можем быстро докопаться до причины. На слайде приведена небольшая стихотворная иллюстрация по этому поводу.

Диаграмма Исикавы

Диаграмма Исикавы – это, по сути, те же самые «5 почему», только усложненный вариант.

Диаграмму Исикавы удобнее использовать, когда причин много и мы классифицируем их по группам, относящимся к оборудованию, к материалам, к методам выполнения работ, к персоналу.

Как ее использовать? Рисуем квадратик, в котором коротко сообщаем суть инцидента, и от него начинаем рисовать вот такую диаграмму (она еще называется «рыбья кость»), на каждой линии которой мы будем размещать вот эти «5 почему», группируя их причины по зонам.

Принцип Парето

А принцип Парето, я думаю, и так уже многим известен: 80% результата можно получить, приложив 20% усилий, а оставшиеся 80% усилий дадут только 20% результата.

Принцип Парето применим в случае, когда инцидент произошел в ходе процесса, на который влияет очень много факторов, и для того, чтобы разобраться, какой из них конкретно вызвал инцидент, мы должны часть факторов отбросить и оставить только те 20% из них, которые дают 80% влияния на результат.

Классификация причин инцидентов.
Корневые причины и корректирующие мероприятия – взаимосвязь с регламентом

Сами причины инцидента делятся на три группы – корневые, сопутствующие и непосредственные. Что здесь важно?

  • Важно всегда определить корневую причину, потому что после устранения корневой причины инцидент не должен повторяться.
  • Непосредственная причина – это то действие, которое вызывало сам инцидент. Это может быть, например, нажатие какой-то кнопки, действие либо бездействие – это та "соломинка, которая переломила спину верблюда".
  • И сопутствующие причины – это те причины, которые усугубили инцидент – они либо усложнили его купирование, либо привели к более тяжелым последствиям.

После того, как причины определены, их всегда необходимо правильно классифицировать, чтобы понять, какая из них является корневой.

Что здесь поможет?

Есть критерий определения корневой причины: корневая причина всегда связана либо с нарушением регламента, либо с его отсутствием, либо с некорректностью самого регламента.

  • Ситуация может быть такая – есть регламент, в котором написано, как делать. Люди обучены и действовали в соответствии с регламентом. Но инцидент возник. Значит, регламент неправильный.
  • Если регламента нет вообще – люди как-то делают, но это их внутреннее тайное знание. Значит, причина – это отсутствие регламента (люди не знают, как делать правильно).
  • И третий вариант – это когда и регламент есть, и люди обучены, и регламент правильный, но инцидент все равно произошел. Значит, эти люди регламент нарушили.

Теперь по поводу корректирующих мероприятий. После выявления причин и их классификации нужно разработать корректирующие мероприятия, которые будут направлены на устранение этих причин. Очень важно, что правильно составленные корректирующие мероприятия обязательно должны завершаться внесением изменений в какие-то регламенты (или их созданием). Фактически, мы должны изменить течение процесса, зафиксировать эти изменения в документации и обучить людей, как действовать правильно.

Акт расследования

Как произвести расследование и правильно составить акт?

  • Нужно записать сам инцидент:  что произошло.
  • Затем нужно коротко указать события, которые предшествовали инциденту и могли привести к его появлению.
  • Далее – нужно расписать хронологию развития инцидента. В хронологии для каждого действующего лица нужно обязательно четко указывать дату, время, фамилию, должность – не просто «Сотрудник склада» или «Ответственный», а конкретно указать фамилию и должность этого человека. Это очень важно, потому что когда мы говорим о конкретных людях, о конкретных должностях, всегда возникает вопрос: а как он должен был поступать в этой ситуации, а что написано в его рабочей инструкции, а вообще где-то, в принципе, написано, что он должен был делать?
  • После этого необходимо указать последствия инцидента;
  • Зафиксировать причины и классифицировать их;
  • И в завершение акта нужно сформулировать новые знания, которые были получены – определить, что же конкретно в процессе шло не так, что привело к появлению инцидента.

Процесс внедрения корректирующих изменений

После того как составлен акт расследования инцидента, он передается на подписание руководителю рабочей группы, которая проводила расследование. И только после этого рабочая группа приступает к разработке корректирующих мероприятий.

Следует отметить, что мероприятия по купированию (по прекращению инцидента) не являются корректирующими. Корректирующие мероприятия всегда направлены на устранение именно выявленных причин. Для планирования таких мероприятий разрабатывается отдельный самостоятельный документ, который не является частью акта.

Как правильно внедрять те корректирующие мероприятия, которые были запланированы?

  • Например, если в партии был обнаружен брак, и мы для его исправления выбрали какое-то техническое решение, нельзя запускать процесс этого исправления сразу массово. Нужно провести тестирование: взять какую-то опытную партию и на нескольких позициях проверить, сможет ли выбранное корректирующее мероприятие нам помочь в действительности или нет?
  • Далее, если первоначальное тестирование прошло успешно, нужно подготовить необходимые ресурсы для полномасштабного внедрения.
  • После подготовки мы, наконец, сможем произвести окончательные изменения.
  • Важный момент – обязательно до начала изменений нужно составить небольшой документ (он может быть буквально на полстраницы текста), в котором сформирован план возврата к первоначальному состоянию.
    Что-то аналогичное применяется и в IT-разработке: прежде чем накатить новый релиз на живую базу, сначала делают бэкап и убеждаются, что этот бэкап работает, а потом пишут себе короткий план из трех пунктов, как можно вернуть базу в исходное рабочее состояние, если вдруг что-то пошло не так.

Пример расследования инцидента

Коротко – пример реального живого расследования инцидента, который произошел совсем недавно. В чем заключалась его суть?

Поступила претензия от клиента о выявлении брака. В ходе расследования было выявлено, что еще до того, как поступила эта претензия, у данной серии приборов обнаружилась проблема, связанная с ошибкой встроенного ПО. Для исправления этой ошибки была выпущена новая версия ПО, и на завод (в производство и на склад готовой продукции) были направлены электронные письма, в которых говорилось о том, что производство этих приборов нужно остановить, а те приборы, которые лежат на складе, нужно вернуть на доработку, чтобы заменить им программное обеспечение. В итоге, несмотря на все эти действия, клиенту все-таки ушли приборы с версией ПО, которая содержала ошибку.

Какие здесь могут быть причины?

  • Собственно, с чего все началось? С того, что на складе были обнаружены приборы, которые отгружать нельзя.
  • Что произошло дальше (точнее, чего не произошло)? Эти приборы не были физически изолированы, не были как-то промаркированы – их нужно было забрать, увезти, наклеить на них красные ярлычки – этого сделано не было.
  • Что дальше? В учетной системе не была произведена процедура блокировки – ни физически на складе, ни в учетной системе не заблокировали.
    • Вопрос – почему не заблокировали в учетной системе? А потому, что нет в учетной системе режима блокировки, потому что приборы данного типа нужно было заблокировать не все (там их несколько типов было – это не конкретный артикул номенклатуры был, а это была целая серия артикулов, причем только произведенные после определенной даты) – такого режима не было.
    • Дальше вопрос – почему не была проведена блокировка запланированной отгрузки? – потому что конструкторы не могут останавливать ни отгрузку, ни производство: нет у них такого режима, когда конструктор при выявлении ошибки может дать команду на остановку конвейера.
    • Почему не была проведена физическая изоляция приборов? Потому что не было выполнено указание конструкторов, содержащее команду на эту изоляцию.
    • А почему оно не было выполнено? Потому что оно пришло по электронной почте, да еще и оказалось, что в нем содержались не окончательные указания, а всего лишь их проект, и поэтому исполнитель приборы все-таки заблокировал, но не те.

И вот такая серия из «Почему?» позволила нам узнать, из-за чего в результате клиенту все-таки ушел брак. И корневой причиной явилось то, что в письме, которое содержало документацию по описанию работы с данной несоответствующей продукцией, ни слова не было сказано о том, как нужно было действовать, если эта продукция обнаружена на складе. Там очень подробно было все расписано – кто, как, в какой последовательности, что делает, кому передает. Но как поступить с бракованной продукцией, выявленной на складе, как ее изолировать и что с ней делать дальше, там указано не было.

Заключение

Собственно, на слайде указано, какие проблемы вас ждут, если вы решитесь у себя это внедрить.

Как с этим бороться и наш опыт того, как мы с этим боролись, я уже рассказал.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

29

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. ihtiking 03.08.16 11:18 Сейчас в теме
Автору большое спасибо за труд публикации статьи, но как то уж надоели эти "ГрафикиДиаграммыРасчётыАнализРегистрацияДетализация и прочее". Всё равно всё сводится к простой формуле: Есть проблема, пиши код и решай её.

Аналитика по типовым причинам, приводящие к инцидентам, может дать только количественную оценку. Например, косяк программиста - 100 случаев, косяк бухгалтерии - 200 случаев. Только вот НА БУДУЩЕЕ предупреждать данные инциденты эта информация не поможет. Программисты приходят\уходят в\из компании. Всю историю не изучишь....
3. Dem1urg 290 03.08.16 19:21 Сейчас в теме
(1) ihtiking, Суть доклада была в том, чтобы рассказать о том, как одна компания попыталась применить системный подход к решению инцидентов. И что из этого получилось.
2. Сурикат 264 03.08.16 18:40 Сейчас в теме
Монументально!
Основная проблема такого подхода очень большая инерционность в принятии корректирующих мер. И их накопление в гигантские кипы инструкций, которые никто не соблюдает.
master555; +1 Ответить
13. Accident 6 08.08.16 12:46 Сейчас в теме
(2) Сурикат, добавлю - не только не соблюдают, но и не читают вовсе..
4. Yashazz 2852 04.08.16 15:06 Сейчас в теме
Пхе. Немножко пересказа ISO и немножко собственного опыта. Честно говоря, утомляют эти жж-образные биографические реминесценции. Ибо бесполезны, хоть будь сто раз красиво оформлены. Что в одной компании пошло "на ура", то в другой забуксует, и нет, на самом деле, никаких выводов и никаких best practice, кроме собственно желания участников процесса двигать оный процесс. А посему - скушно, братцы.

Если каждый начнёт мемуарами страдать, тут же не продохнуть будет... Может, лучше и правда просто делом заниматься, а?

Я вот могу рассказать, как одна немаленькая компания не без моей помощи СКК внедряла, и-таки внедрила... Ровно для того, чтобы немецкие аудиторы, строгие ребята из TUV SUD, нужные бумажечки нам выдали. Надо ли говорить, на каком уровне при этом было и осталось истинное качество, или сами догадаетесь?
master555; +1 1 Ответить
5. starik-2005 1960 04.08.16 17:43 Сейчас в теме
(4) Yashazz, ну это ИТИЛ - английская методология систем, работающих на базе инцидентов и создающих библиотеку знаний, позволяющую на часто встречающиеся инциденты реагировать быстрее с каждым разом. Ну и цепочка постоянного улучшения. Да, ничего нового, но лучше это прочитать, чем не прочитать - такое вот мое ИМХО.

Но вообще все сводится к хелпдеску...
Прикрепленные файлы:
Arrigo; Accident; +2 Ответить
7. Dem1urg 290 05.08.16 10:16 Сейчас в теме
(5) starik-2005, Не нужно сужать рамки до ITIL и HelpDesk. Понятия инцидента намного шире. И инструментов для управления процессом изменений больше.
Я специально в докладе не делал акцента именно на ИТ. Да, зачастую, защитой от многих "мелких" инцидентов является автоматизированная информационная система, работа с которой построена таким образом, чтобы пользователь не мог сделать что-то неправильно (контроль заполненности реквизитов, контроль остатков при проведении документа и т.п.). Но не нужно ограничиваться этим.
8. starik-2005 1960 05.08.16 12:11 Сейчас в теме
(7) Вы просто не читали шесть томов ITIL, походу. Я не сузил - я расширил.
14. Accident 6 08.08.16 12:52 Сейчас в теме
(5) starik-2005, Полностью согласен.
Ps Статья читабельная. Для ознакомления самое то..
Саму методологию ИТила можно несколько лет постигать, ну это если кому интересно..
16. speshuric 1120 09.09.16 21:35 Сейчас в теме
Моё личное мнение:

Абсолютно правильно сказано, что на начальном этапе главная задача - регистрировать инциденты. А чтобы они регистрировались нужно несколько условий:
1. Одно окно. Или хотя бы "мало понятных окон". Причем "ошибся окном" - проблема окна, а не инициатора.
2. Инцидент создать просто. А лучше он сам создаётся. В том числе по непроизошедшим событиям.
3. НЕ НАКАЗЫВАТЬ ЗА ИНЦИДЕНТЫ. НИКОГДА. Даже если разбор показал что причина - конкретный сотрудник. Соблазн очень велик. Но нет. Если и наказывать, то за нерегистрацию, за задержки на передаче на "простых" этапах, за отсутствие реакции и неактуальность статуса, за неустранение проблем (если они были найдены и выделены ресурсы на устранение). Но никогда не за количество инцидентов. "У отдела А много инцидентов, давайте их лишим премии" - это п... конец вашей системе инцидентов.
4. БД инцидентов должна быть актуальна. Каждый день. По каждому исполнителю.
5. При автоматическом создании инцидентов нельзя спамить (да-да, "Волк! Волк!")

Чтобы поток инцидентов был управляемым:
1. Разделите "управление инцидентами" и "управление проблемами". В этой статье это смешано. На первых порах это нормально, но в итоге лучше разделить.
2. Из предыдущего пункта следует правило: инцидент закрыт НЕ тогда, когда устранена причина, а тогда, когда восстановлен сервис (или согласовано снижение уровня сервиса). На первый взгляд это неправильно, и, действительно, это требует определённой зрелости остальных процессов, но это важно.
3. Как логичное продолжение: Баг - не инцидент. Инцидент это событие потенциального или фактического снижения уровня сервиса, а баг - это неотъемлемое свойство программы. Да, часть багов приводит к инцидентам и является их причиной.
4. Прозрачные и однозначные правила приоритетов инцидентов. Прозрачный и однозначный порядок эскалации (как "вертикальной", так и "горизонтальной"). И в этом месте соглашусь с (5), (8), что лучше было бы имплементировать ITIL-подход. Нет там никакой космической сложности, но некоторые неочевидные грабли уже убраны.
5. Линейный (или почти линейный) и простой жизненный цикл инцидента. Переоткрытие инцидента - это маленькое ЧП. Если инцидент был устранен, но проблема снова возникла, то это новый инцидент (правда уже серийный, с соответствующими последствиями). Проблема у двух пользователей - скорее всего два инцидента, но один будет закрыт как дубликат со ссылкой на первый зарегистрированный.
6. По всем инцидентам, кроме катастроф и полных авралов всё общение в инциденте. В катастрофах и авралах заставлять вести историю самого бесполезного участника (это может быть и начальник какой-нибудь)

Типовые инциденты не надо расследовать. Это не значит, что не надо устранять причину. Причина находится и устраняется в управлении проблемами. Но вот заводить бюрократию вместо типового решения не следует. Абстрактный пример. Инцидент "перегорела лампочка". Каждый раз причина понятна (лампочка перегорела). В рамках предыдущих инцидентов стало понятно, что должен быть запас пампочек, он теперь на складе есть. Договорились в SLA, что нормальный срок устранения такого инцидента N минут. Зачем каждый раз расследовать? Будете заставлять расследовать у вас будут глупые решения: нанять сотрудника, который будет весь день ходить и проверять лампочки, менять лампочки каждую неделю, разработать и внедрить автоматизированную систему отслеживания работоспособности лампочек. Не надо. Просто если есть инцидент - поменяй лампочку. Это не перестаёт быть инцидентом.

Главный вопрос в управлении инцидентов - сбалансированная и аккуратная мотивация (разная для разных участников).
Dem1urg; Артано; +2 Ответить
17. speshuric 1120 09.09.16 21:47 Сейчас в теме
(16) speshuric,
Уточню: Не наказывайте за инциденты рядовых исполнителей и нижний (линейный) уровень менеджмента. Средний и высший менеджмент за серьёзные инциденты в их зоне ответственности может пострадать (но не всё подразделение).
18. Dem1urg 290 15.09.16 11:40 Сейчас в теме
(17) speshuric, Это очень важное условие. В докладе я упоминал, что на начальном этапе внедрения процесса было прямое распоряжение высшего руководства содержащее явный запрет любого наказания для всех участников инцидента.
6. Dem1urg 290 05.08.16 10:12 Сейчас в теме
(4) Yashazz, Рад, что у вас столь богатый профессиональный опыт, что вам такое уже неинтересно. Без подколов, на самом деле рад.
Но. Целью доклада и данной статьи не являлось развеять чью-либо скуку.
Цель - показать ситуацию под определенным углом зрения, в надежде, что это поможет кому-то посмотреть на привычные вещи по новому. И придумать, как он может улучшить работу свою или своей компании.
Arrigo; Accident; +2 Ответить
9. vandalsvq 1129 05.08.16 19:17 Сейчас в теме
Форма регистрации сообщения (инцидента) это конечно жуть, слишком как то наворочено.
По идее сначала регистрация и подтверждение сообщения, при чем назначение ответственных за разбор дальнейший не всегда реален и целесообразен.
Далее решают уже аналитики, ну или главарь технической банды (если вообще не сделать двойной вариант: персональное назначение + рынок свободных задач).
Собственно по результату реализации можно уже делать задачу по разработке механизма предотвращения.
Ну это просто, поток мыслей.

Пы.сы. если на картинке схемы бизнес-процесса реальный программный процесс - это просто беда, паника, истерика. Процессы должны быть простыми и понятными, желательно без множеств ветвлений и возвратов. С другой стороны хозяин барин и если надо наладить бюрократию, то начало неплохое ))))))
10. Dem1urg 290 05.08.16 23:52 Сейчас в теме
(9) vandalsvq, Процесс абсолютно реальный и он работает. В базе уже несколько тысяч инцидентов. Чтобы схема (карта маршрута) поместилась на слайде, её пришлось нарисовать "змеей". Если развернуть процесс в "линию" он будет выглядеть значительно проще. Ветвлений не много, а все возвраты возникают только если исполнитель предыдущего этапа сделал свою работу некачественно.
11. saveug 19 07.08.16 11:34 Сейчас в теме
Вот интересно, точка входа в управление инцидентами только одна - пользователь, но ведь бывают инциденты, генерируемые автоматически (средства мониторинга и т.п.). С другой стороны, если в процессе работы приложения произошел сбой, то зачем надеяться, что пользователь обратится за решением проблемы? Ведь можно подключить автоматические средства уведомления об инциденте.
12. starik-2005 1960 08.08.16 11:34 Сейчас в теме
(11) saveug, так и делают. Просто в качестве заказчика тут выступает ИТ, как создатель алгоритма проверки функционала. Робот от имени ИТ и создает данный инцидент, являющийся следствием работы алгоритма проверки на ошибочную ситуацию. В остальных случаях, когда робот не может распознать ошибку, заказчиком инициатором является пользователь. Регулярные ошибки уже могут облекаться в алгоритм, контролирующий те или иные параметры работы системы. И это не только ИТ проблем касается, но и проблем учета. Например, при превышении суммы отгрузки клиенту возникает инцидент, адресованный уполномоченному по данным вопросам сотруднику (или их группе). Если превышение оплаты по заявке на расходование ДС не выше определенного, то инцидент может быть создан финансовому контроллеру, если выше - просто отклонен. Ну и так далее...
15. mulla1979 8 08.08.16 18:08 Сейчас в теме
Оставьте свое сообщение

См. также

Незакрытый проект на 1000 часов 62

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    6858    ogroup    153       

Стратегия выживания в корпоративных войнах 47

Статья no Нет файла Бесплатно (free) Управление проектом

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    4028    GSoft    14       

Мастер-класс СППР 39

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    3232    SergeyN    4       

Быстрый старт: минимальный набор автоматизации типовых процессов 21

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом

Автоматизация дает множество преимуществ бизнесу, но в то же время ее выгода может быть настолько несущественной, что процесс принесет компании больше убытков, чем прибыли. С чего начать эффективную автоматизацию, какие процессы стоит автоматизировать на первом этапе, а какие – лучше оставить на потом, рассказала руководитель разработки систем учета компании «Едадил» Екатерина Золотарева.

16.08.2019    3658    Hissin    18       

Как заработать миллион или История успешного сотрудничества 45

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    4043    karpik666    77       

Бизнес-аналитика с помощью Power BI 65

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Тема статьи – это бизнес-аналитика. Возможно, кто-то этого не знает, но внедрение бизнес-аналитики – это очень больно. Когда внедряются не просто какие-то дашборды, а действительно бизнес-аналитика, происходит увольнение большого количества сотрудников, потому что выясняется, что они не выполняют те функции, которые на них возложены.

11.07.2019    6294    pbazeliuk    18       

Управление проектами по автоматизации бюджетирования 35

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    3174    SergeyN    1       

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов 22

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    2630    sbase    9       

Риск - благородное дело!.. Часть первая 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    3797    MariaTemchina    8       

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

31.05.2019    4104    MariaTemchina    23       

Как продать проект в 3 раза дороже и нанести клиенту пользу, выполнив не внедрение... 22

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Практически все российские компании нуждаются не просто в установке 1С:ERP, 1С:Документооборота или какой-то другой программы, а в масштабных организационных изменениях, но мало кто из заказчиков это понимает. Те, кто занимается 1С, могут помочь бизнесу решить его проблемы, а заодно и продать проект внедрения в несколько раз дороже. Как это сделать, на конференции INFOSTART EVENT 2018 EDUCATION рассказал собственник и директор компании «Корада» Алексей Бояршинов.

27.05.2019    4150    cybrat    9       

Устав писать Устав 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    4013    MariaTemchina    8       

Как сжать время? 22

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом Личная эффективность

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    4674    1c-intelligence    39       

Путь джедая в управлении проектами 1С: умение быть, а не казаться 36

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    6730    MariaTemchina    15       

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 16

Курс Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    9216    infostart    18       

Стыд и Скрам, часть вторая 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Крик души про иллюзию внедрения Agile. Продолжаем разговор про сложности, с которыми мы сталкиваемся, когда под видом гибких технологий используются "топорные" директивные методы. По сути, мы в очередной раз сталкиваемся с извечным конфликтом "сурового менеджмента" и "творческих разработчиков"

14.03.2019    7720    MariaTemchina    47       

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?" 38

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    4396    chavalah    22       

Стыд и скрам - Чему нас учит Scream Guide 29

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    6051    MariaTemchina    20       

Бизнес, не горюй 33

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    5744    1c-intelligence    64       

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения 23

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Тема управления проектами - популярная, вокруг нее много всего разного накручено. Кто-то считает, что главное - это выучить PMBOK и точно следовать правилам. Кто-то считает, что главное создать комфортную атмосферу, и сразу все как по волшебству заработает. В этой статье я попробую рассказать, какие шаги, по моему скромному мнению, нужно предпринять, чтобы начать более эффективно управлять проектами в организации.

31.01.2019    4963    MariaTemchina    0       

Ошибки управленцев: как топ-менеджеров убивает перфекционизм 5

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    6107    user809424    11       

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан 31

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

14.01.2019    6567    MariaTemchina    13       

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях" 62

Статья no Нет файла Бесплатно (free) Управление проектом

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    8935    chavalah    123       

Где мы взяли флакон? 38

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

История появления и развития методики

26.12.2018    6172    1c-intelligence    7       

Озарение после прочтения макулатуры по проектному управлению 42

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    6454    MariaTemchina    24       

20 мыслей об ИТ-проектах, или 20 лет спустя. 53

Статья no Нет файла Бесплатно (free) Управление проектом

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    5908    chavalah    119       

Памятка руководителя: не играйте с деньгами 83

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность Управление персоналом (HRM)

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    13190    andironenko    128       

Шаг назад и ... шаг назад (классификация внутренних проектов) 34

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Во многих остросюжетных фильмах используется этот трюк. В начале фильма главный герой одиноко скачет по прерии лицом к хвосту лошади, или закопан в пустыне по самое горло, или какие-то не совсем добрые люди собираются отрезать ему то, что отрезать и не нужно. Потом идут титры, потом на весь экран спойлер: двумя неделями раньше... и здесь он хлещет виски в салуне, прикуривает от сто долларовой банкноты, рассекает на яхте с пятнадцатилетней капитаншей. Все то, что так не рекомендует делать Минздрав. И уже весь остальной фильм нам рассказывают, как можно собственно докатиться от такой до такой жизни. Такая же история приключилась и с прошлой статьей.

03.12.2018    5494    capitan    26       

Белая и пушистая рецензия на Чёрную книгу Скрам 31

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Данный текст является ответом на "Черную книгу Скрам" Ивана Селиховкина. Честно скажу, несмотря на то, что рукопись вряд ли предназначалась моему взору, прочитала ее на одном дыхании.  Публикую рецензию как есть - свое имя автор, к сожалению, не написал.

26.11.2018    6650    MariaTemchina    40       

Черная книга Скрам 21

Статья Бизнес-аналитик Пользователь Руководитель проекта Архив с данными Бесплатно (free) Управление проектом

Наблюдения менеджера, разрушившего карьеру бездумным применением Скрам. Рекомендации и предостережения.

26.11.2018    5483    356    Selikhovkin    4       

"Черные страницы Scrum", по версии Ивана Селиховкина 21

Статья no Нет файла Бесплатно (free) Управление проектом

Иван Селиховкин более 12 лет занимается управлением проектами, программами, портфелями. И в статье он расскажет о проблемах использования Scrum, которые могут поставить под угрозу вашу карьеру или ваш проект, если вы неловко неудачно примените этот фреймворк.

23.11.2018    7802    Selikhovkin    8       

Памятка руководителя: Будьте оптимистичным или на крайний случай злым 46

Статья no Нет файла Бесплатно (free) Блоги Управление проектом

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    8873    andironenko    43       

Scrum за 5 минут (заметки) 25

Статья no Нет файла Бесплатно (free) Управление проектом

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    5065    leobrn    11       

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8 30

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Что такое концепция проекта? Это понятие, близкое по смыслу к техническому заданию (ТЗ). Одно из определений концепции - детальное, целостное описание работ в удобной для команды форме.

19.11.2018    4909    Selikhovkin    1       

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия) 35

Статья no Нет файла Бесплатно (free) Управление проектом

Так уж получилось, что на сайте я представляю средний класс. А именно программистов и сисадминов, работающих не у франчайзи и не на фрилансе, а в обычных ИП, АО, ООО, и т.п., основная деятельность которых, никаким образом с производством программных продуктов не связана. Посему все удивительные рассказы Марии Темчиной про Agile это как анекдот...

19.11.2018    6248    capitan    41       

Почему внедрение ERP-системы не приносит пользы бизнесу? 87

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Интеграция Управление проектом

Статья посвящена проблеме, с которой сталкивается большинство специалистов по внедрению информационных систем ERP класса - завышенные ожидания от этих систем. Обсудим, что клиент ожидает, что получает и почему успех или провал проекта для него почти равнозначны.

15.11.2018    15622    rossoxa    62       

Думать некогда, трясти надо - или что такое ретроспектива в Agile 30

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    7247    MariaTemchina    16       

Памятка руководителя: В одиночку здесь не выжить 43

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    9233    andironenko    62       

Приоритизировали, приоритизировали, да не выприоритизировали... 28

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В ответ на классическое требование "сделать всё и сразу" Agile предлагает "сделать сразу, но не всё". В этой статье я хочу поговорить о разных методах приоритизации требований.

30.10.2018    6085    MariaTemchina    47       

Памятка руководителя: Уволь HRа и найди себе хороших сотрудников 67

Статья Руководитель проекта Нет файла Управление персоналом (HRM) Бесплатно (free) Управление проектом

Продолжаю цикл «Памятка руководителя». Эта статья будет на тему поиска новых сотрудников и одной грубой ошибки при проведении собеседования.

29.10.2018    8884    andironenko    35       

Принцип быстрой автоматизации 22

Статья Программист Нет файла Бесплатно (free) Управление проектом

Как выполняется автоматизация в бизнес-программировании?

29.10.2018    6306    1c-intelligence    19       

Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть" 34

Статья no Нет файла Бесплатно (free) Управление проектом

Харитонов Михаил описывает проект по внедрению интеграционной сервисной шины предприятия (ESB) «2iS:Интеграция» на платформе “1С:Предприятие 8” в компании ПАО «Газпром нефть». Проект уникален тем, что это – первое решение, использующее отечественное ПО в качестве полноценной интеграционной шины для столь крупного заказчика с обширным ИТ-ландшафтом. В статье подробно рассмотрена архитектура решения, способы тестирования и масштабирования.

17.10.2018    7320    Mick2iS    8       

#БезОценок, или Как перестать беспокоиться об оценке проекта, всегда успевать в срок и укладываться в бюджет 32

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Считается, что для планирования и принятия решений по проектам их нужно прогнозировать и оценивать. Александр Белов, генеральный директор и руководитель проектов ГК «Белов и партнеры», рассказывает, почему стоит отказаться от оценок.

11.10.2018    5214    AlexWhite    7       

Профессиональные стандарты в ИТ как инструмент кадровой политики организации 21

Исследование Программист Пользователь Руководитель проекта Нет файла Обучение, бизнес-тренинг, курсы ИТ-компания 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free) Управление проектом

Представляем результаты нашего нового исследования, посвященного теме профессиональной стандартизации и сертификации в сфере ИТ. Одна из главных задач работы – показать, каким образом профстандарты могут быть полезны в практике управления ИТ-персоналом предприятия.

08.10.2018    7693    39    infostart    4       

Построение высокоэффективной Agile-команды 34

Статья no Нет файла Бесплатно (free) Управление проектом

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    5194    askhatu    15       

История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum 106

Статья no Нет файла Бесплатно (free) Управление проектом

Статья описывает успешный опыт реализации проекта после перехода от классической технологии «каскада» к методологии Scrum. Автор приводит примеры конкретных инструментов для построения эффективных коммуникаций в команде, ведения технической и пользовательской документации, реализации Scrum-доски, проведения стендапов и т.д. Также в статье даются рекомендации для тех, кто хочет научиться применять Scrum в своей деятельности.

01.10.2018    13314    glebushka    41       

Контракты Agile: как заключать договора в условиях расползания содержания 41

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В большинстве проектов, реализуемых при помощи гибких методологий, точное содержание продукта невозможно выяснить на этапе инициации. Отсюда и возникает крик души руководителей проектов – «Как можно заключить контракт, не понимая точный бюджет проекта?» В статье я попробую рассмотреть этот вопрос с двух сторон: рекомендации от идеологов Agile и опыт реальных практиков. 

25.09.2018    6771    MariaTemchina    10