Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Учим администраторов (MBA). Версия 1.1 -- жесткие (т.е. спорные) тезисы

Я решил переписать заново предыдущий текст: не столько учесть к нему замечания, сколько укоротить и заострить сказанное.

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

2. Существует множество различных разбиений функции менеджмента на позиции/роли/функции (организация-руководство-управление в СМД-методологии, producer-administrator-entrepreneur-integrator Ицхака Адизеса, человек мысли-человек действия-человек людей-человек переднего края Дракера, а также смежные с ними прежде всего экономические различения предприниматель-инвестор-наемный менеджер, противопоставление менеджера и бюрократа, принципала и агента). В большинстве случаев выделяется особая роль администратора, как организатора людей, компьютеров и механизмов в систему по эффективному получению результатов. Поставим задачу готовить блестящих администраторов из людей, имеющих способности к администрированию -- и давать этим администраторам удовлетворительную подготовку в других областях менеджмента. То есть вернуться к первоначальному значению MBA как "мастера администрирования", но с учетом всех накопленных к 2007г. "мощных идей" в области администрирования.

3. Суть администрирования -- это создание и контроль эффективно достигающей заданных целей организации -- системы из людей, компьютеров и другой техники. Организация -- это в зависимости от механистичности метафоры "машина по получению результатов", "слаженно работающий организм", "команда единомышленников" и т.д. Задача администратора -- построить такую организацию, контролировать ее работу, непрерывно изменять организацию в зависимости от меняющихся целей.

4. Основная деятельность администратора тем самым сводится к вопросам организации (программирования) деятельности людей, компьютеров и другой техники. Организовывание (программирование) -- это деятельность по составлению инструкций для коллектива других деятелей (исполнителей). Грубо говоря, администратор -- это тот, кто пишет регламенты, планы/расписания и отслеживает затем их выполнение. Тот, кто организует процесс исполнения работы, тот кто программирует людей, компьютеры и механизмы -- и добивается того, чтобы люди, компьютеры и другая техника эффективно взаимодействовали. Оставим пока в стороне вопрос о возможностях (полномочиях, таланте лидерства) админстратора вменять другим людям (а также контролируемым другими людьми компьютерам и другой технике) подготовленные им регламенты и планы/расписания. Важно отметить, что администратор должен быть грамотным программистом: его регламенты, планы/расписания (программы) должны на данном ему множестве исполнителей приводить к эффективному достижению целей организации. Цели организации в общем случае ставит не он (хотя вполне возможно совмещение ролей организатора и предпринимателя в одном лице).

5. Нужно особо отметить, что работа администратора и компьютерного программиста имеет много общего: оба планируют выполняемые в будущем операции, обеспечивая при этом эффективность используемых ресурсов и синхронизацию операций во времени. Это программистский аспект работы администратора.

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

7. При подготовке администратора ему нужно будет поставить программистское мышление (в смысле computer science с несколько переставленными акцентами) -- а именно, возможность свободного рассуждения и решения задач в области распределенного выполнения набора синхронизированных ресурсоемких операций в распределенной исполняющей среде. Основное, с чем приходится иметь дело администратору -- это ресурсы и время. Исполнители, потребляющие при работе ресурсы, синхронизируются друг с другом, передавая сообщения друг другу устно, через физические носители (тележки JIT, конвейер), или через информационную систему. Администратор должен понимать, что "управление процессами", "управление проектами", supply chain management, integral resource planning, operation management -- это все про одно и то же: связанное с различными органичениями и определяемое различными контекстами выполнение цепочек операций людьми, компьютерами и прочей техникой. [РЭШ готовит экономистов с математической подготовкой. Ну, а мы будем готовить администраторов с программистской подготовкой].

8. Администрирование должно также обеспечивать прозрачность и подотчетность не только для себя, для других менеджерских ролей (а также для "хозяина организации", если это не сама менеджерская команда).

9. Администратор должен хорошо понимать в управленческом учете (и не только финансовом) -- сборе и хранении нужной для менеджмента информации.

10. Администратор должен понимать разницу в организации государственного управления и организации частного сектора.

11. Подготовка администратора сводится не к изучению best practices и многочисленных кейсов, сколько к мыслительному освоению некоторого набора "мощных идей" и опыту применения их в реальных (или имитирующих реальные ситуации). Вот некоторый примерный (неполный и неструктурированный) набор таких идей:
-- представлять деятельность нужно не в терминах "конкретных людей", а в терминах их позиций (ролей). Многопозиционный взгляд на ситуацию ("постмодерн"), симултрек.
-- техники снятия организационных конфликтов, и наоборот: перевод в позиционный конфликт конфликта интересов
-- организовывание и программирование (в том числе компьютерное) -- это про одно и то же. Речь не идет о "кодировании", а о полном жизненном цикле: анализ требований, дизайн, кодирование, отладка, выпуск новых версий и т.д.
-- важность не только подбора и организации исполнителей, но и организации среды, через которую исполнители передают друг другу материалы и сообщения (тележки JIT, компьютеры, ведущие управленческий учет). Все сообщения должны фиксироваться, логи обязательны -- иначе отладка процесса будет невозможна.
-- антропоморфность объектного подхода (актёры-роли-костюмы), "машинность" работы с людьми (рабочие места, "исполнители").
-- люди -- это не компьютеры и не homo economicus. Нефинансовая мотивация, работа с человеческими ценностями.
-- спиральная динамика. Уровни развития людей, уровни развития организации.
-- agile-подходы к организации/программированию (само организовывание, равно как и программирование выполняется в рамках agile-подхода. Это требует специальной "исполнительной среды" -- так, XP было рождено при написании Smalltalk-программ, в которых сам процесс программирования существенно отличается от широко распространенных в силу особенностей среды смолток-разработки).
-- "Планирующая игра" в организовывании и исследовательских проектах, и "игровые ходы" как метод работы (т.е. процедуры, предусматривающие переговоры и достижение согласия между позиционерами).
-- итерационность всего (не так важна любая структура, как шаги по ее изменению). Упор не на сами величины, а на их приращения ("маржинальность"). Не на состояния, а на процессы их изменения.
-- цикл непрерывного улучшения как цикл работы с ограничениями (TOC). Понятие сложной системы и простой системы в связи с ограничениями/Рефакторинг.
-- различные алгоритмы составления расписаний (прежде всего -- барабан-буфер-веревка, критическая цепочка, управление по временнЫм буферам)
-- организация как "трубопровод, по которому идет throughput". Replenishment и pull как основные способы организовывать движение материалов по организации/системе.
-- цель любой фирмы -- зарабатывание денег сейчас и в будущем (важен долгосрочный прирост throughput, а не его значение).
-- раздельный учет переменных и постоянных затрат (а не рентабельность и себестоимость)
-- софтверное моделирование деятельности с целью ее анализа (модель нужна, "чтобы померять то, что нельзя измерить в реальности")
-- софт поддержки workflow -- это учебный софт исполнителей этого workflow (и этот же софт -- среда разработки для администратора)
-- внедрение новой организации работ (очередной версии явных или неявных регламентов) зачастую -- это внедрение нового софта, поддерживающего эти новые регламенты.
-- "толерантность" (граница перфекционизма) -- пример с Визой и "воруют"
-- главный вопрос "чем не нужно заниматься", а не "что еще можно сделать" (использование сложности системы)
-- и так далее (что еще? ;)

12. Особенности учебного процесса подготовки администраторов будут обсуждены особо. Но это не классно-урочная система.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 33 comments