У меня уже был материал про то, почему проекты автоматизации могут провалиться. Одним из пунктов я отдельно упомянул целенаправленный саботаж. Хочу в данном материале немного углубиться в эту тему и рассказать несколько известных мне примеров.
«Мы работаем по agile» — обычно с такой фразы начинают представление компании опытные продавцы услуг IT услуг. «Ммм, я такое слово слышал, кажется это что-то модное», — думает человек на другом конце трубки, — «Эти ребята наверное крутые». Но не спешите делать выводы — применение гибких методик не гарантирует результат и не делает IT компанию «крутой» по-умолчанию. Почему? Расскажу ниже.
В автоматизацию обычно верят, как в пилюлю от всех болезней. Вот внедрим (crm, erp, bpm, wms – нужное подчеркнуть) – и сразу всё будет красиво, прозрачно и контролируемо. Большой начальник сидя в своём большом кабинете нажмёт волшебную кнопку и сразу получит все отчёты, в нужных разрезах и с нужной глубиной аналитики. О том почему счастье не случается – я уже писал раньше. Сегодня взгляд на проблему с другой стороны. Поговорим про данные и деньги.
Кто о чём, а я опять про качество сервиса. Тема Customer Development подробно и детально описана во множестве источников. Я же хочу взглянуть на тему через призму ITSM и DevOps практик, а также попытаться вынести идеи CusDev за рамки IT и культуры стартапов, применив к другим видам и направлениям бизнеса.
Сегодня будет не очень обычный для меня пост. Это мой первый пост который не даёт ответы на вопросы или рекомендации — а скорее приглашение к дискуссии и попытка понять какие-то базовые вещи для самого себя. А для начала причина этого материала:
Пожалуй, самый животрепещущий вопрос управления – что и как
измерять, чтобы контролировать процесс. Как выбрать показатели, которые будут
адекватным образом отражать положение дел, и что из них должно стать KPI для сотрудников?
Этим материалом начинаю цикл статей, посвящённых измерениям
процессов в IT. Сегодня
про основы.
Вдохновившись идеями библиотеки ITIL решил попробовать внедрить у себя
систему оценок, которую пользователи ставят за выполнение обращений в службу
технической поддержки. После недолгих манипуляций с нашей ServiceDesk системой запилили
функционал. Разослали пользователям инструкции о том как выставлять оценки,
подкреплённые просьбой выставлять оценки за закрытые задачи. Но что-то пошло не
так…
Вместо предисловия, выдержка из ITIL Service Strategy:
«Многие компании верят, что приобретя или разработав какой-то инструмент, все их проблемы будут сразу решены. Но очень просто забыть о том, что они всё ещё зависят от процессов, функций и, что особенно важно, людей. И запомните – дурак с инструментом – всё ещё дурак».
Сегодня мои размышления про выбор программного обеспечения.
Мы все любим себя. В той или иной степени. Гордимся своими достижениями и стараемся при возможности их показать. Это очень сильно заметно например в тренажёрном зале. Не успел ты набрать (ну, или сбросить, в зависимости от целей) 1-2 кило как уже вместо эффективных занятий всё чаще заглядываешь в зеркала, так удачно развешанные по всему залу, поигрывать мышцами на публику и всячески себя со всех сторон осматривать. Думаю, многим такое знакомо. Признаюсь честно, я тоже вёл себя так и очень быстро заметил, что результаты приходят медленнее, а тренировка становится не такой эффективной. Я нанял тренера, который составил мне программу тренировок и ходил за мной по залу от первого до последнего упражнения. Всё записывал и контролировал. И что произошло? Правильно, тренировка стала эффективнее, результаты заметнее и приходили быстрее. И вот какая мысль мне пришла в голову. А ведь очень часто так же происходит и с организацией работы. Ты выстраиваешь систему управления, налаживаешь процессы, пишешь регламенты и правила и дико гордишься тем, как у тебя всё хорошо работает. Но так ли это на самом деле? Читать далее