Комментарии 14
Вот тяжело, реально. Супер технологии, масштабное описание. А вот берешь трубку и боишься (я про поддержку) — что на том конце будет бразильянка на своем английском с тобой говорить. Знание языка тут не поможет — выручает конечно текстовый чат.
0
Так с места в карьер написано, будто бы все читатели знают, что такое Mars. Или работают в Mars.
+1
А некоторые даже не знают о существовании такой компании :(
0
Где-то заплакал маркетолог Марса, вспоминая о былом величии в 90-х.
0
Чуть больше о нас можно узнать в одной из наших первых публикаций: habr.com/company/marsis/blog/338886
0
Простите, а чем, всё-таки, вы сейчас хвалились? 12.000 изменений — это что, например?
+1
У нас не было задачи хвалиться, у нас была задача поделиться нашим опытом. С одной стороны, кому-то это может быть полезно, с другой стороны мы бы хотели узнать об опыте других компаний. Может быть нам следует что-то изменить в нашем подходе. Процесс постоянно эволюционирует.
0
Изменения могут быть абсолютно разными, начиная от изменения какой-нибудь кастомной процедуры и заканчивая релизом новой версии ERP системы. В этом и есть смысл подхода, с точки зрения процесса не должно быть различия между изменениями по умолчанию. Это задача усовершенствования процесса, когда чтобы увеличить эффективность процесса появляются стандартные изменения, темплейты и т.д.
0
Большое спасибо за статью, вы здесь поделились своим опытом, но во что не понятно — как этот опыт может быть полезен другим компаниям? Большинство подобных статей можно подвести под общий заголовок «как мы в большой компании Х внедрили процесс Y». Т.е. я говорю о том что в компаниях, которые созрели для процесса Y, он скорее всего уже внедряется по своему уникальному сценарию, а в компаниях которые не созрели для этого — он не нужен и может даже мешать бизнесу.
0
Наш основной опыт во внедрении процесса управления изменениями(Change Management) заключается в том, что этому нужно уделять большое внимание и иметь людей, которые за этим процессом следят и этот процесс постоянно развивают. Процесс не многим отличается от того, что описано в ITIL. Раньше этот процесс тоже существовал, но к сожалению не был таким эффективным или в некоторых случаях вообще ему не следовали. Мы решили вложиться в людей занимающихся процессом(всего 4 человека глобально) и это принесло определенные результаты. Например мы смогли больше активностей отдать на аутсорс.
Конечно все компании находятся на разной стадии развития и не всем это нужно, но может быть кому-то эта sccess story будет полезна.
Конечно все компании находятся на разной стадии развития и не всем это нужно, но может быть кому-то эта sccess story будет полезна.
0
Пересказ ITSM скучен для тех, кто с ним знаком, и непонятен для остальных. А вот ошибки случаются чтобы на них учится. Расскажите про несколько epic fails года, как процесс помог сделать их менее epic, чем было бы без него, и какие процесные или организационные изменения внесли с учётом полученного опыта.
Tell the Story. Pure theory and stats are boring.
+1
К счастью, у нас не было epic fails, которые могли бы подвергнуть риску весь бизнес. Так как у нас нет систем, недоступность которых способна остановить весь бизнес глобально. Но критические fails случались.
Наша задача не заключалась в том, чтобы устранить специфические ошибки: не в этом суть change management процесса. Хотя число ошибок сократилось значительно. В частности, например, сократилось число Emergency изменений. Благодаря новому процессу и строгости, с которой мы отслеживали соблюдение сроков, их стало в 2-3 раза меньше. В итоге, мы уменьшили риски возникновения ошибок, т.к. Emergency Change – это гораздо больший риск.
Второй пример – это фокус на недопустимость неавторизованных изменений. Последствия за подобные нарушения могут быть весьма серьёзными, что стимулирует их не совершать.
Наша задача не заключалась в том, чтобы устранить специфические ошибки: не в этом суть change management процесса. Хотя число ошибок сократилось значительно. В частности, например, сократилось число Emergency изменений. Благодаря новому процессу и строгости, с которой мы отслеживали соблюдение сроков, их стало в 2-3 раза меньше. В итоге, мы уменьшили риски возникновения ошибок, т.к. Emergency Change – это гораздо больший риск.
Второй пример – это фокус на недопустимость неавторизованных изменений. Последствия за подобные нарушения могут быть весьма серьёзными, что стимулирует их не совершать.
0
Цифры это ерунда.
Как вы решили проблему «мистера Брента» (см. книгу «Проект Феникс»)?
Как вы решили проблему «мистера Брента» (см. книгу «Проект Феникс»)?
0
DEL
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление изменениями в ИТ-инфраструктуре компании Марс