Согласен со всеми идеями автора, причём применительно не только к ИТ подразделению, но и к любому другому
Единственное, что важно понимать, что данный подход 'как есть' хорошо работает при размерах департамента численностью до 150-200 человек, а при размерах функции в 5000-8000 человек, подход уже будет схожий, но намного более сложносочинённый и эффекты принятых решений будут проявляться с задержкой в 6-8 месяцев.
В части определения квалификации команды я следую принципу 'учить-лечить-мочить' и для начала пытаюсь понять, совпадаем ли мы с ними в самих принципах управления, постанрвки задач и отношения к работе. Если не совпадаем, то корректирую(иногда и свою картину мира) и, если не помогла коррекция, то расстаёмся. Но в моём случае это применимо, если есть не меньше 2 уровней управления.
Мы оба друг друга не до конца поняли.
Основной мой посыл — начальник ИТ в нормальной компании — это топ-менеджер и выше его только генеральный/исполнительный директоры, совет директоров и т.п.
Т.е. любой другой руководитель/директор — по факту, это один уровень и в этом случае споры решаются уже в несколько ином ключе.
Из своего опыта для меня логичным и нормальным является тот вариант, когда ИТ-менеджер выступает посредником между бизнесом и ИТ и решает проблемы бизнеса с помощью ИТ.
НО, я категорически не принимаю вариант, когда ИТ-руководитель находится в оппозиции бизнес-руководителям и всеми руками держится за свою власть и место даже в ущерб бизнесу.
В этом случае, в штате компании необходим сотрудник, отвечающий за бизнес-процессы как таковые и понимающий, обе стороны — и бизнес и ИТ. Будь то специалист по бизнес-процессам или бизнес-аналитик, но его не должны пугать такие слова как BPMN,ARIS, IDEF и одновременно для него должно быть родными слова AD, XML, .NET/Java, SOAP, REST, SLA, инцидент, проблема, управление конфигурацией и т.п.
PS. Я бы сначала определился со списком процессов взаимодействия бизнеса и ИТ и о том, как они должны быть реализованы. Т.е., ЧТО ИМЕННО хочет контролировать бизнес, в каком виде, как часто. Взаимодействие с пользователями — это лишь 50% работы ИТ-отдела, а
остальное — это уже взаимодействие с бизнесом и собственные внутренние процессы.
Кстати, очень рекомендую достаточно простую для понимания книгу — Роб Ингланд (ИТ-Скептик), «Овладевая ITIL». Найти, где её скачать несложно ( распространяется в pdf ).
По итогам прочтения и ответа самому себе и ИТ-директором на вопросы из неё можно уже делать детальный план и выбирать способы достижения целей проекта упорядочивания деятельности
начальник другого отдела может на совещаниях перед гендиром из раза в раз кидать фразу, что мол задачу ИТшнику поставил, а он подлец не сделал
В этом случае, если он не является его непосредственным начальником, то руководитель ИТ просто ставит его задачу ( проект? ) в очередь, правильно расставив приоритеты.
Единственное — это реалистично только для достаточно большой компании со зрелым управлением бизнесом. В ином случае — это всего лишь мечта об идеальном мире
Тут всё зависит от бизнеса, на самом деле.
Если ИТ-отдел — это чисто техническая вспомогательная служба во главе с главным сисадмином, то да, бизнесу на этот отдел как то по барабану, а если в сферу ответственности ИТ входят бизнес-процессы и в той или иной степени менеджмент качества, то в этом случае ИТ — это бизнес-партнёр.
Лично для меня -сервис-деск — это всего лишь один из «интерфейсов», пускай и один из ключевых, для взаимодействия пользователей и ИТ-отдела.
Как уже описано Sergey-S-Kovalev немного ниже — первые шаги надо смотреть по его плану, с которым я целиком и полностью согласен.
От себя добавлю — самое главное — п.1 — ЗАЧЕМ это всё бизнесу. Даже не ИТ-отделу.
PS. Если бизнесу не нужно от слова «совсем», то можно на всё забить.
Без настоящей, деятельной поддержки уровня гендиректора небольшой компании — ничего не взлетит.
Если попробовать сократить описание рисков ( отправив читать соответсвующие книги или хотя бы ИТ-скептика), думаю — многим будет интересна статья, особенно с тем учётом, что подобных я как то на хабре и не упомню.
Особенно в разрезе «для малых компаний»
А сколько всего у Вас в компании работает человек и сколько ИТ-сервисов уровня инфраструктуры и приложений?
Кстати, AD *nix и Mac вполне себе умеют через LDAP-коннекторы. А современные версии, по моим данным, это умеют «почти» из коробки без излишних «танцев с бубном»
Крупные компании часто проводят собственные обучения( всевозможные школы, внутренние университеты и т.п.)
Часто по итогам они берут стажёров работать «за еду», но при этом они уже внутри компании и у них есть все шансы вырасти дальше при наличии способностей.
Попробуйте рассмотреть вариант стажёрства, просто засылая резюме в крупные компании ( даже, если у них нет подходящих вакансий)
Не сможете. Не маштабируется, введение новых хотелок будет вызывать ад. А со временем запросы от руководства будут только расти.
Полностью поддерживаю. Мы, в своё время по этой же причине изначально выбрали веб-решение ( Zendesk). Пускай и относительно кривое
Расскажите мне про это когда количество обслуживаемых вами пользователей через один портал перейдет, скажем, за 3 тысячи :)
Из своего опыта знаю, что уже 300 территориально распределённых сотрудников приведёт к обезличиванию
Все остальное почтой.
Почтовые заявки, кстати, в относительной степени и с определённым видом модерации реально обрабатывать сразу через ServiceDesk-систему, а если в компании что то типа Lotus Notes или есть возможность внедрить в почтовый клиент хотя бы частично формализованные заявки, то почтовый канал станет основным
Им всегда проще позвонить. Максимум — написать письмо.
Всё зависит от компании — в некоторых может быть ровно наоборот.
По поводу звонков — моё предложение — делать скрипты для операторов/диспетчеров — чтобы они во время звонка заводили заявки и выяснил всю необходимую информацию.
Если такой должности нет, то её стоит ввести — т.е. единый номер телефона для приёма заявок оператором. Немного пострадает клиентоориентированность, но на порядок снизится нагрузка на более квалифицированных сотрудников.
| И у нас именно пользователь должен подтвердить, что проблема устранена. Только после этого закрывается заявка.
Мы, со своей стороны, следуем такой схеме закрытия заявки в её жизненном цикле:
Выполнена (Solved) — изменяется статус и инженер ТП описывает решение заявки в том или ином виде. После этого отправляется предложение оценки решения автору заявки ( даже если за него её завёл диспетчер). Из этого состояния заявка может быть переоткрыта (reopen).
Закрыта (Closed) — пользователь оценил решение или автоматически через 2 недели при отсутствии реакции пользователя. Состояние финальное и переоткрытию не подлежит
У нас в требованиях указано что пользователь должен подробно описать проблему
Но не все эти требования выполняют.
Из своего опыта — наши сотрудники уточняют у автора заявки — что он имел ввиду ( если нет пометки «срочно» или это не VIP-клиент) в письменном виде и ждут уточнения ( SLA считается только тогда, когда заявка на стороне поддержки). Пользователей тоже надо учить правильно пользоваться сервисами.
Для меня, в первую очередь, руководитель ( начальник, менеджер и т.п. ) — это человек, способный и берущий на себя ответственность за результат деятельности не только себя, но и за своих подчинённых. Организатор. И не только за оперативный результат, но и за результат в долгосрочной перспективе.
Если вся команда действует в одном направлении и 100% сотрудников отвечают требованиям выше — то тогда да, менеджеры действительно не нужны.
Но, к сожалению, пример 37signals, — это исключение, подтверждающее правило — бОльшая часть рядовых сотрудников с трудом берёт на себя ответственность в полной мере даже за свою работу, а не то что за результат деятельности других.
На мой взгляд, это нормально — есть специалисты, которым нравится быть специалистом и профессионалом и всегда иметь ответ на вопрос "КАК?", а есть ИТ-менеджеры, которые являются переводчиками потребностей бизнеса в конкретные действия ИТ и они знают ответ на вопрос "ЗАЧЕМ?"
На мой личный взгляд, в компании среднего размера ( ну или в небольшой, но с высокими потребностями в ИТ-инфраструктуре) должны быть оба — и сисадмин-инженер, и ит-менеджер
В любом Enterprise такого уровня, почти всегда такое же мнение, как у Вас =)
PS. Это вечный холивар: своё дело — офис в малой/средней компании — крупный Enterprise — у каждого варианта свои плюсы и минусы и каждый сам выбирает то, что ему ближе
Естественно, я сам придерживаюсь аналогичного подхода и абсолютно не понимаю «культ карго» для любой методологии/стандарта.
На мой личный взгляд — всему есть своё место, но в обязательном порядке, для любой методологии надо глубоко понимать её суть и ответить самому себе на вопрос «Зачем?»
Интересная история успеха и способ её реализации. Успехов и удачи в поддержании системы на должном уровне!
У меня вопрос — есть ли связка процессов ИТ-службы и процессов планирования( развития) бизнеса? Или это уже более высокий уровень, который не зависит от Вас никак?
PS. Вам встречался стандарт COBIT 5? На мой взгляд, некоторые подходы оттуда могут дополнительно упорядочить.
PPS. Приятно видеть, что есть достаточное количество ИТ-руководителей, считающих, что ITIL — это не панацея.
Очень большая и несколько «тяжеловато» читается и не совсем понятно структурирование, несмотря на то, что это расшифровка доклада. Возможно, имеет смысл поискать/попробовать другие варианты структурирования или донесения содержания?
Где то к концу трети статьи, появилось устойчивое впечатление, что разговор идёт о том, как применять и зачем нужна стратегия «голубого океана»
PS. Такой вариант для меня на порядок лучше 60-и минутного видео с докладом )
Это то естественно — поэтому стандартный вопрос на собеседованиях — почему ушёл человек оттуда, а со своей стороны обязательно надо проверять — чем же те компании занимаются
Согласен со всеми идеями автора, причём применительно не только к ИТ подразделению, но и к любому другому
Единственное, что важно понимать, что данный подход 'как есть' хорошо работает при размерах департамента численностью до 150-200 человек, а при размерах функции в 5000-8000 человек, подход уже будет схожий, но намного более сложносочинённый и эффекты принятых решений будут проявляться с задержкой в 6-8 месяцев.
В части определения квалификации команды я следую принципу 'учить-лечить-мочить' и для начала пытаюсь понять, совпадаем ли мы с ними в самих принципах управления, постанрвки задач и отношения к работе. Если не совпадаем, то корректирую(иногда и свою картину мира) и, если не помогла коррекция, то расстаёмся. Но в моём случае это применимо, если есть не меньше 2 уровней управления.
Основной мой посыл — начальник ИТ в нормальной компании — это топ-менеджер и выше его только генеральный/исполнительный директоры, совет директоров и т.п.
Т.е. любой другой руководитель/директор — по факту, это один уровень и в этом случае споры решаются уже в несколько ином ключе.
Из своего опыта для меня логичным и нормальным является тот вариант, когда ИТ-менеджер выступает посредником между бизнесом и ИТ и решает проблемы бизнеса с помощью ИТ.
НО, я категорически не принимаю вариант, когда ИТ-руководитель находится в оппозиции бизнес-руководителям и всеми руками держится за свою власть и место даже в ущерб бизнесу.
PS. Я бы сначала определился со списком процессов взаимодействия бизнеса и ИТ и о том, как они должны быть реализованы. Т.е., ЧТО ИМЕННО хочет контролировать бизнес, в каком виде, как часто. Взаимодействие с пользователями — это лишь 50% работы ИТ-отдела, а
остальное — это уже взаимодействие с бизнесом и собственные внутренние процессы.
Кстати, очень рекомендую достаточно простую для понимания книгу — Роб Ингланд (ИТ-Скептик), «Овладевая ITIL». Найти, где её скачать несложно ( распространяется в pdf ).
По итогам прочтения и ответа самому себе и ИТ-директором на вопросы из неё можно уже делать детальный план и выбирать способы достижения целей проекта упорядочивания деятельности
В этом случае, если он не является его непосредственным начальником, то руководитель ИТ просто ставит его задачу ( проект? ) в очередь, правильно расставив приоритеты.
Единственное — это реалистично только для достаточно большой компании со зрелым управлением бизнесом. В ином случае — это всего лишь мечта об идеальном мире
Если ИТ-отдел — это чисто техническая вспомогательная служба во главе с главным сисадмином, то да, бизнесу на этот отдел как то по барабану, а если в сферу ответственности ИТ входят бизнес-процессы и в той или иной степени менеджмент качества, то в этом случае ИТ — это бизнес-партнёр.
Лично для меня -сервис-деск — это всего лишь один из «интерфейсов», пускай и один из ключевых, для взаимодействия пользователей и ИТ-отдела.
От себя добавлю — самое главное — п.1 — ЗАЧЕМ это всё бизнесу. Даже не ИТ-отделу.
PS. Если бизнесу не нужно от слова «совсем», то можно на всё забить.
Без настоящей, деятельной поддержки уровня гендиректора небольшой компании — ничего не взлетит.
Особенно в разрезе «для малых компаний»
Кстати, AD *nix и Mac вполне себе умеют через LDAP-коннекторы. А современные версии, по моим данным, это умеют «почти» из коробки без излишних «танцев с бубном»
Часто по итогам они берут стажёров работать «за еду», но при этом они уже внутри компании и у них есть все шансы вырасти дальше при наличии способностей.
Попробуйте рассмотреть вариант стажёрства, просто засылая резюме в крупные компании ( даже, если у них нет подходящих вакансий)
Из описания, разработчик — Ongair сделал общую платформу для SD, которая уже интегрируется с Zendesk и Freshdesk
Пример — Telegram Connect for Zendesk
Полностью поддерживаю. Мы, в своё время по этой же причине изначально выбрали веб-решение ( Zendesk). Пускай и относительно кривое
Из своего опыта знаю, что уже 300 территориально распределённых сотрудников приведёт к обезличиванию
Почтовые заявки, кстати, в относительной степени и с определённым видом модерации реально обрабатывать сразу через ServiceDesk-систему, а если в компании что то типа Lotus Notes или есть возможность внедрить в почтовый клиент хотя бы частично формализованные заявки, то почтовый канал станет основным
Всё зависит от компании — в некоторых может быть ровно наоборот.
По поводу звонков — моё предложение — делать скрипты для операторов/диспетчеров — чтобы они во время звонка заводили заявки и выяснил всю необходимую информацию.
Если такой должности нет, то её стоит ввести — т.е. единый номер телефона для приёма заявок оператором. Немного пострадает клиентоориентированность, но на порядок снизится нагрузка на более квалифицированных сотрудников.
Мы, со своей стороны, следуем такой схеме закрытия заявки в её жизненном цикле:
Но не все эти требования выполняют.
Из своего опыта — наши сотрудники уточняют у автора заявки — что он имел ввиду ( если нет пометки «срочно» или это не VIP-клиент) в письменном виде и ждут уточнения ( SLA считается только тогда, когда заявка на стороне поддержки). Пользователей тоже надо учить правильно пользоваться сервисами.
Если вся команда действует в одном направлении и 100% сотрудников отвечают требованиям выше — то тогда да, менеджеры действительно не нужны.
Но, к сожалению, пример 37signals, — это исключение, подтверждающее правило — бОльшая часть рядовых сотрудников с трудом берёт на себя ответственность в полной мере даже за свою работу, а не то что за результат деятельности других.
На мой личный взгляд, в компании среднего размера ( ну или в небольшой, но с высокими потребностями в ИТ-инфраструктуре) должны быть оба — и сисадмин-инженер, и ит-менеджер
Всё зависит от того, как мерить достаточные деньги и где жить.
PS. Это вечный холивар: своё дело — офис в малой/средней компании — крупный Enterprise — у каждого варианта свои плюсы и минусы и каждый сам выбирает то, что ему ближе
На мой личный взгляд — всему есть своё место, но в обязательном порядке, для любой методологии надо глубоко понимать её суть и ответить самому себе на вопрос «Зачем?»
У меня вопрос — есть ли связка процессов ИТ-службы и процессов планирования( развития) бизнеса? Или это уже более высокий уровень, который не зависит от Вас никак?
PS. Вам встречался стандарт COBIT 5? На мой взгляд, некоторые подходы оттуда могут дополнительно упорядочить.
PPS. Приятно видеть, что есть достаточное количество ИТ-руководителей, считающих, что ITIL — это не панацея.
PS. Такой вариант для меня на порядок лучше 60-и минутного видео с докладом )