Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Никакого "над API" и "под API" не будет

В феврале 2015 в оборот было запущено обсуждение архитектуры предприятия будущего как состоящей из компонент (позиций/профессий/jobs) "над API" и "под API", причём профессии "под API" в свою очередь делятся на "автоматизацию менеджента" и "роботов" (http://www.forbes.com/sites/anthonykosner/2015/02/04/google-cabs-and-uber-bots-will-challenge-jobs-below-the-api/):

Главная идея тут в том, что middle management заменяется API -- вся диспетчеризация уходит в софт. Менеджеры принимают решения о том, как настроить API, менеджеры больше не поручают работы и не контролируют их выполнение (http://rein.pk/replacing-middle-management-with-apis/). И после этого говорится, что выживут только те содержательные профессии, которые будут заказчиками работ, а исполнители работ все будут автоматизированы (сначала в части менеджмента, а потом и вообще заменены роботами). В Uber останутся только пассажиры и API, а таксисты все будут заменены роботами.

Мне кажется, что тезис абсолютно неверный: по факту над API остаются не столько "работы-профессии", сколько просто потребительские позиции (позиция пассажира над API, позиция таксиста под API, а сам API выполняет функции линейного менеджмента). В подобной фразеологии говорится, что в предприятии остаются только строители API (пользовательский интерфейс клиента и диспетчеризация работ) и роботостроители (пока роботостроители заменяются создателями пользовательских интерфейсов для работников "под API"). Тотальная автоматизация (http://ailev.livejournal.com/1131557.html -- humans need not to apply), только и всего, ничего нового кроме замечания что профессионалы "под API" перестают иметь шанс повышения и переквалификации, ибо вряд ли из таксистов можно пойти в программисты диспетчерских программ того же Uber.

Но вот тезис о дисинтермедиации содержательных (инженерных, производственных) работников путём ухода внутрь софта функций диспетчирования ресурсов (чем и занимается по большей части инженерный менеджмент) -- это да, этот тезис выживает. Дальше можно обсуждать, насколько можно упихнуть в API лидерство (например, как обеспечивается лидерство среди таксистов Uber или Яндекс-такси). Или насколько подобный менеджмент будет съедать всё менее и менее коммодитизируемые работы (всё-таки поездки в такси и другие потребительские сервисы довольно однородны). Или насколько речь идёт о внешнем по отношении к фирме API (приём и распределение заказов), или подобные рассуждения можно применить и по отношению к корпоративным информационным системам управления работами (PLM, ERP, EAM и т.д.).

Тут нужно заметить, что речь идёт о довольно редкой архитектурной парадигме -- коммуникационной (а не продуктной и не процессной), то есть мы говорим о функционировании предприятия как о сети поручений на работу upstream и выполнении этих поручений downstream (напомню про DEMO -- http://ailev.livejournal.com/644440.html) и лидерство тут в том, чтобы минимизировать отказы/саботажи в выполнении поручений. В принципе, lean-kanban-TOC тоже можно рассматривать как попытку формализовать как-то работу инженерного менеджера, это подход к постановке задачи по созданию подобного софта. Да, там очень много противоречащих друг другу принципов и правил, но это не мешает потихоньку делать соответствующий солвер-планировщик и вымывать линейных менеджеров из организации. Это, конечно, не исключает автоматизацию работ как над, так и под таким API -- автоматизацию всего "вокруг API". Слово API при этом просто начинает обозначать корпоративный софт, ничего более. Разнообразие архитектур предприятий с учётом перехода менеджерских функций к софту сейчас поднимется.

Шапкозакидательно? Конечно. Но уже сейчас довольно много линейных менеджеров просто прокладки между работниками и какими-нибудь корпоративными информационными системами (проектного управления, ERP, EAM). Читают информацию с экрана и доводят её до содержательных работников, затем спрашивают у содержательных работников и вводят эту информацию на экран. Прям телефонистки на старинных ATC. И не нужно говорить, что интерфейс телефона много проще, чем интерфейс корпоративного софта. Хороший пользовательский интерфейс к содержательным работникам вполне с коммуникацией справится, даже если ему придётся при этом принять форму робота телеприсутствия и говорить на разных диалектах производственного матерного языка и отпускать пошлые шутки в целях управления вниманием работников.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 2 comments