Tag Archives: управление

Кто они, наши пользователи? Второй шаг ИТ-начальника.

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

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

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

1. Каков возрастной состав пользователей, какие основные возрастные группы и каково процентное соотношение этих групп?

2. Какой образовательный состав пользователей?

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

4. Насколько основная работа пользователей зависит от качества работы ИТ-подразделения?

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

В качестве иллюстрации привожу историю из рельной жизни. На промышленное предприятие, вполне адекватно автоматизированное для своего времени и бюджета пришел новый тольковый начальник ИТ-подразделения. На заводе к тому времени была уже вполне зрелая, созданная в советские годы система обработки информации по их основной деятельности — производственные рассчеты, складские задачи, учет продукции и так далее. Блок бухгалтерской и кадровой информации тоже вполне успешно функционировал на основе 1С и некоторого количества самописных задач. С помощью простых, но эффективных костылей всё программное обесечение было объединено в громоздкий, но успешно работающий комплекс. Главным было то, что, в силу консервативности основных заводских технологических процессов, система автоматизации вполне справлялась с поставленными задачами даже без больших усилий на модернизацию.

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

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

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

С чего начать, когда не знаете, за что зацепиться?

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

Очевидно, начинать нужно с того, чтобы разобраться, что и как работает. Преждем чем улучшать, обычно хотя бы ориентируются, что и где нужно улучшить. Хотя бывает и так, что начинают с глобальной перестройки, с того, что сразу все переставляют на некие «новые рельсы», и этот подход (удивительно!) иногда работает.

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

Что такое регламент? Что такое инструкция? Что такое процедура? Чем регламент отличается от инструкции? Что считать инцидентом, что не считать? Что такое служебная записка? Что такое автоматизированное рабочее место (АРМ), а что не считается АРМ? Как называется та совокупность железяк и программных средств, с которой вы собираетесь работать — корпоративная информационная система (КИС), просто информационная система (ИС) или информационно-аналитическая система (ИАС)? Как называется и является ли частью ИС сегмент Интернета, развернутый на предприятии?

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

К сожалению, я практически не знаю мест, где это делается не формально, а фактически, с пониманием важности данного процесса. Не буду объяснять, почему это важно (хотя есть масса аргументов, начиная с библейский «… В начале было слово!…» и заканчивая вполне современными бизнес-практиками и рекомендациями). Скажу по своему опыту: пока система понятий не будет уточнена, нормально общаться будет невозможно, и на эти грабли будете наступать снова и снова. Более того, если только сформулировать основные понятия и их не уточнять, уже через пару лет целый ряд терминов устареет, и это будут самые важные термины, потому что раз они устарели, то именно в этой области идет развитие, их и надо уточнять!

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

Почему из хороших инженеров получаются плохие управленцы

Вообще говоря, то, что вынесено в заголовок, не факт. Бывает и наоборот, получаются отличные управленцы, также как и хорошие актеры или музыканты, не говоря уж о писателях. Я оставляю за читателем возможность найти, какие ВУЗы и кто по первой профессии актер Филиппенко, писатель Задорнов, и так далее. А уж приличных управленцев — огрмное количество.

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

  1. Попытки все сделать самому, особенно тогда, когда сам можешь сделать лучше. О, это настоящий бич управленцев с инженерным прошлым. Даже если они не в плену иллюзий, что сами могут сделать порученную задачу лучше исполнителя, то подключение их к решению вопроса является грандиозной ошибкой. Будучи управленцами, они тогда откладывают зачастую куда более приоритетные, но скучные задачи, чтобы решить инженерную проблему. Этот инженерный перфекционизм съедает массу времени, заставляет тратит время на переключение между задачами и даже когда дает выигрыш на коротком участке проекта, как правило, тормозит проект в целом. А еще страшнее, если управленец ошибается в том, что может сделать что-то намного лучше того, кому поручено (а это тоже бывает, даже у хорошего инженера с течением времени теряется хватка, уходит свежесть мышления и устаревают знания). Тогда к указанному выше добавляются прямые потери от ошибочных действий по решению конкретной инженерной задачи.
  2. Реакция на ошибки. Что чувствует хороший инженер, когда что-то идет не так? Он чувствует личную вину, горечь и глубокое разочарование в себе, потому что если что-то идет не так, то это личная недоработка, личный просчет, личный неучет чего-то существенного. Что для управленца ситуация, когда что-то идет не так? Это нормальный рабочий фон, всегда что-то и где-то идет не так, кто-то болеет, кто-то подводит, кто-то обманывает или уходит на другую работу. Так вот, когда инженер становится управленцем, он продолжает чувствовать личную вину за каждый «косяк» всего процесса в целом, и, даже если сдерживается, то продолжает себя жрать изнутри со страшной силой. Поэтому зачастую работа управленца инженеру не приносит особого удовлетворения — психологический фон не тот, постоянно всякая фигня происходит.
  3. Круг общения. Это безумное везение, когда вокруг управленца из среды инженеров другие управленцы хотя бы из похожей среды. Намного страшнее и хуже, когда вокруг — выпускники специализированных ВУЗов с управленческими дипломами, которые всю жизнь занимаются только управлением. У них с бывшим инженером практически не совпадают системы оценок, прошлый опыт, база личных знаний и критерии оценки. Причем и те, и другие относятся друг к другу в лучшем случае с недоверием, а в худшем — с разной степенью скрытым презрением. Если в среде инженеров худо-бедно есть объективные основы для прогноза, то в управленческой деятельности (кстати, как и в военном искусстве) только потом (и то не всегда) понятно, было ли принятое решение верным или нет. Так что поводов относится к себе с недоверием или даже презрением и инженеры, и дипломированные управленцы дают с избытком. Поэтому многократно мною было видено, как напряжены инженеры на всяких управленческих тусовках.

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