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

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

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

В статье речь пойдет про инциденты в несколько более широком смысле, чем это описано в 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.

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

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

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

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

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

Но вообще все сводится к хелпдеску...
Прикрепленные файлы:
Arrigo; Accident; +2 Ответить
7. Dem1urg 322 05.08.16 10:16 Сейчас в теме
(5) starik-2005, Не нужно сужать рамки до ITIL и HelpDesk. Понятия инцидента намного шире. И инструментов для управления процессом изменений больше.
Я специально в докладе не делал акцента именно на ИТ. Да, зачастую, защитой от многих "мелких" инцидентов является автоматизированная информационная система, работа с которой построена таким образом, чтобы пользователь не мог сделать что-то неправильно (контроль заполненности реквизитов, контроль остатков при проведении документа и т.п.). Но не нужно ограничиваться этим.
8. starik-2005 2227 05.08.16 12:11 Сейчас в теме
(7) Вы просто не читали шесть томов ITIL, походу. Я не сузил - я расширил.
14. Accident 6 08.08.16 12:52 Сейчас в теме
(5) starik-2005, Полностью согласен.
Ps Статья читабельная. Для ознакомления самое то..
Саму методологию ИТила можно несколько лет постигать, ну это если кому интересно..
16. speshuric 1189 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 1189 09.09.16 21:47 Сейчас в теме
(16) speshuric,
Уточню: Не наказывайте за инциденты рядовых исполнителей и нижний (линейный) уровень менеджмента. Средний и высший менеджмент за серьёзные инциденты в их зоне ответственности может пострадать (но не всё подразделение).
18. Dem1urg 322 15.09.16 11:40 Сейчас в теме
(17) speshuric, Это очень важное условие. В докладе я упоминал, что на начальном этапе внедрения процесса было прямое распоряжение высшего руководства содержащее явный запрет любого наказания для всех участников инцидента.
6. Dem1urg 322 05.08.16 10:12 Сейчас в теме
(4) Yashazz, Рад, что у вас столь богатый профессиональный опыт, что вам такое уже неинтересно. Без подколов, на самом деле рад.
Но. Целью доклада и данной статьи не являлось развеять чью-либо скуку.
Цель - показать ситуацию под определенным углом зрения, в надежде, что это поможет кому-то посмотреть на привычные вещи по новому. И придумать, как он может улучшить работу свою или своей компании.
Arrigo; Accident; +2 Ответить
9. vandalsvq 1170 05.08.16 19:17 Сейчас в теме
Форма регистрации сообщения (инцидента) это конечно жуть, слишком как то наворочено.
По идее сначала регистрация и подтверждение сообщения, при чем назначение ответственных за разбор дальнейший не всегда реален и целесообразен.
Далее решают уже аналитики, ну или главарь технической банды (если вообще не сделать двойной вариант: персональное назначение + рынок свободных задач).
Собственно по результату реализации можно уже делать задачу по разработке механизма предотвращения.
Ну это просто, поток мыслей.

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

См. также

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

Управление проектом Бесплатно (free)

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

24.01.2019    9971    user809424    11    

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

Управление проектом Бесплатно (free)

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    1674    MariaTemchina    8    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

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

11.09.2020    2807    alexandr.blinov    17    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    3033    MariaTemchina    23    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    34698    1СERP    79    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

Управление услугами и сервисом Управление бизнес-процессами (BPM) Управление прочее Управление проектом Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    2826    MariaTemchina    4    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4425    1c-intelligence    17    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

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

08.06.2020    4992    stepan96    12    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31297    1СERP    175    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5509    sapervodichka    1    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    11023    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

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

23.03.2020    5875    MariaTemchina    24    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    32282    1СERP    189    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    6356    VLikhobabin    44    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Waterflow Бесплатно (free)

В новой версии PMBoK традиционные рекомендации по управлению проектами перевернуты с ног на голову. В этой статье расскажу свою точку зрения, в чем, на мой взгляд, основные изменения, и как это может сказаться на проектах внедрения…   

23.01.2020    16617    MariaTemchina    8    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    7341    roman72    0    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

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

10.04.2017    32217    1СERP    107    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6811    1c-intelligence    33    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

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

14.10.2019    5995    chavalah    16    

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

Управление проектом Россия Бесплатно (free)

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

19.09.2019    12509    ogroup    163    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    43106    1СERP    231    

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

Управление проектом Бесплатно (free)

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

16.09.2019    9961    GSoft    16    

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

Управление проектом СППР Бесплатно (free)

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

30.08.2019    12652    SergeyN    8    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    9051    Arsen1986    7    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    27777    Gavrik    10    

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

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

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

16.08.2019    8461    Hissin    18    

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

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

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

28.06.2019    8284    SergeyN    1    

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

Управление проектом Бесплатно (free)

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

24.06.2019    6865    sbase    9    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

Не так давно на одном из проектов во время инвентаризации была выявлена очень большая недостача. Как результат, одно из важнейших требований клиента по проекту было: разобраться с тем, что у него происходит в системе, и привести остатки, как он выразился, «в адекватное состояние». А незадолго до этого у меня в практике был случай, когда уже на второй день после внедрения качественной системы учета движения наличных денежных средств (кассы) также была выявлена недостача, но уже в кассе. И в первом, и во втором случае вину за возникновение проблемы представители заказчика попытались возложить на людей, которые занимались внедрением новой системы. И только после долгих и, надо признаться, довольно неприятных и очень эмоциональных разбирательств, удалось доказать клиенту, что система работает правильно, а виноваты в случившемся сотрудники компании, которые намеренно или ненамеренно создали фактическую недостачу товара и денег.

17.06.2016    40364    raiml    37    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

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

19.06.2019    10395    FB_10160810658600104    62    

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

Управление проектом Бесплатно (free)

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

18.06.2019    7698    MariaTemchina    8    

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

Управление проектом Бесплатно (free)

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

31.05.2019    9491    MariaTemchina    23    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    44905    CheBurator    64    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    11342    1c-intelligence    121    

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

Управление проектом Бесплатно (free)

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

06.05.2019    7767    MariaTemchina    8    

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

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

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

04.05.2019    9036    1c-intelligence    39    

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

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36379    axxell    15    

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

Управление проектом Бесплатно (free)

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

15.04.2019    12008    MariaTemchina    15    

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

Управление проектом Бесплатно (free)

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

13.02.2019    8305    chavalah    22    

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

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

12.02.2019    10221    MariaTemchina    20    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.04.2015    37883    raiml    14    

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

Управление проектом Бесплатно (free)

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

04.02.2019    10214    1c-intelligence    64    

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

Управление проектом Бесплатно (free)

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

31.01.2019    8386    MariaTemchina    0    

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

Управление проектом Бесплатно (free)

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

14.01.2019    10287    MariaTemchina    13    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

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

16.11.2014    28845    raiml    46    

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

Управление проектом Бесплатно (free)

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

10.01.2019    13038    chavalah    123    

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

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

26.12.2018    10018    1c-intelligence    7    

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

Управление проектом Бесплатно (free)

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

19.12.2018    9974    MariaTemchina    24    

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

Управление проектом УУ Бесплатно (free)

Я не буду здесь давать сухие определения, думаю, они никому не интересны. Бизнес-консультант – это тот самый человек, которого приглашают со стороны, чтобы он помог найти решение каких-то проблем. Также очевидно, что взгляд «со стороны» очень часто помогает выявить то, что вы никогда не обнаружите, будучи сотрудником компании. Я хочу с вами поговорить исключительно о бизнес-консультантах, которые работают с малым и средним бизнесом, т.к. с предприятиями с численностью сотрудников ориентировочно от 5 до 70 человек. Эта работа во многом отличается от того, что делают специалисты, которых привлекают в подобных случаях крупные компании. И, как раз, с этими нюансами есть смысл разобраться.

13.11.2014    28053    raiml    236    

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

Управление проектом Бесплатно (free)

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

09.12.2018    9289    chavalah    119    

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

Управление проектом Личная эффективность Управление персоналом (HRM) Бесплатно (free)

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

05.12.2018    17240    andironenko    128    

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

Управление проектом Бесплатно (free)

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

03.12.2018    8818    capitan    26