Мне кажется, что я пишу как минимум дипломную работу :) К слову, мне известно, что мои материалы некоторыми студентами для подобной цели уже использовались - я ничего против не имею, даже приятно. Считаю полезным.
Так вот, постепенно я подвожу свой рассказ к проблемам, которые обязательно встанут на пути внедрения электронных систем управления авиакомпанией. Конечно, я не смогу покрыть все, но попробую вспомнить о самых главных. А для начала я хочу показать картинку - семейство AIMS. Авиакомпании, которые использовали данный продукт год назад
Читать предыдущую часть
Видеть наш "хвостик" среди таких брендов, как Qatar Airways, Etihad, Easy Jet, Airl Berlin (и даже Boeing!) - знаете ли, очень приятно. И, если в поездке в Катар мы увидели много чего нового и красиво организованного, у нас было много вопросов, которые катарцами уже решились, то через полгода мы посетили DHL в Лейпциге и поняли, что в сравнении с немцами, с тем, как они используют возможности автоматического планирования AIMS (никак - все вручную, даже обновление Expiries!) мы смотримся вполне достойно.
Но в далеком 2011-м году, когда встала задача осуществить внедрение, мы были несколько чрезмерно оптимистично настроены, т.к. не понимали до конца всех проблем, которые надо решить для успешного перехода со старых рельс на новые.
Итак, если Вы собираетесь внедрять зарубежный продукт (здесь и далее речь идет об афинском AIMS, но, скорее всего, все равнозначно и для других) в компании советского типа, то готовьтесь к тому, что Вам придется решать многие трудности.
1. Информационный вакуум, обилие слухов и стержень внушения
Я намеренно вынес это на первое место. Если Вы хотите внедрить что-то радикально новое, то сначала не поленитесь провести разъяснительную работу среди всего персонала о причинах, целях и планах изменений.
Например:
а) Назревшая необходимость
б) История проблем, обоснование необходимости
в) Какие прибыли сулит данное нововведение компании
г) Вкусности, которые ощутит каждый пилот после перехода на новые рельсы
д) Проблемы, которые ожидаются на пути перехода
е) Изменения в привычный уклад работы, в мышление, которые произойдут в процессе перехода.
Если Вы замкнете информацию в "клубе по интересам" - т.е., среди руководителей очень высокого ранга, а вниз будете спускать лишь разрозненные слухи: "да, будем внедрять.. будем сокращать, так как надо оптимизировать" - уверяю, в скором времени Вы получите очень сплоченную оппозицию из тех, кто чувствует себя лишним в будущем периоде... Да-да, я говорю об "отцах-командирах", комэсках.
Вот они-то (за редким исключением) как раз и обеспечат информационный настрой коллектива и агитподготовку таким образом, что малейшая ошибка, малейший дискомфорт (а шишек в начале пути будет очень много), малейшие отступления от привычного стиля работы будет вызывать просто шквал эмоций в адрес "ничего-не-смыслящих-в-планировании-дево
Точно так же будет вести себя и командир летного отряда, для которого комэски гораздо ближе, чем "манагеры", он так давно с ними работает, что уже считает данную компанию своей семьей, а себя отцом. Поэтому он будет горой стоять за своих подчиненных из самых лучших (на его взгляд) побуждений.
Поэтому не менее важно - сразу расставить все точки над i для всех руководителй. Показать стержень своих планов - изменения нужны, они будут, это аксиома. Не обсуждаются. Значит, следующий вопрос - как мы будем внедрять? Какие предложения?
Очень хорошо сформулировал мысль один человек, участвовавший во внедрении с самого начала. Мне ее ретранслировал такой же "ветеран внедрения", Олег, участник моих прошлых рассказов об AIMS (поездка в Катар, в Лейпциг). Смысл такой:
"Он думает, что это его личная компания? Ни фига. Это ЧАСТНАЯ авиакомпания. Владелец сказал: "Я хочу, чтобы мы внедрили AIMS", выделил деньги для этого, значит, все, решение принято. Ты должен усраться, но работать для исполнения требования владельца. Если ты идешь против, значит ты работаешь против компании, против человека, который является твоим работодателем, платит тебе зарплату. За что ему платить зарплату в этом случае? Не согласен - уходи с должности, увольняйся, но не мешай".
Кстати, Олег - неплохая идея - сочинить орден "ветеран внедрения" :) Можно еще поставить мемориал в честь павших: "Они сражались за AIMS" :)
На тему внедрения нового (в том числе автоматизированных систем упраления предприятием) написано много статей. И все они говорят об одном и том же - одной из главных проблем является то, что люди не хотят менять привычный стиль работы. Их все устраивает, они получают зарплату, им непонятны цели изменений - "все и так работает, зачем менять?", "работало же, что вы тут придумали - все разрушить?", "не трожь, не сломается".
Соответственно, вторая проблема вытекает из первой
2. Проблема "внедрителей" - ответственных и исполнителей.
Это, наверное, самый глобальный вопрос. Кадры решают все.
Очень и очень и очень важно правильно подойти к вопросу ответственных руководителей и исполнителей - от самого главного, отвечающего за процесс внедрения, до отдельных ответственных за те или иные процессы.
Ну не будут хорошо работать те, которые страстно не хотят никаких изменений! То, что "он 35 лет на командно-руководящих должностях!" еще не гарантирует того, что он соображает в том, что надо делать для перехода на новые рельсы! Более того, с большой долей уверенности (практически 100% случаев) можно сказать, что именно эти люди будут противниками любых нововведений, которые им непривычны и непонятны.
Нивелировать неприятие (и даже саботаж, чего уж стесняться - надо называть вещи своими именами) со стороны руководителей начального и среднего звена можно лишь двумя способами:
а) Информационной промывкой мозгов еще до начала внедрения
б) Отстранением от должности. Возможно, что и с последующим увольнением, если генеририрование саботажа продолжится.
Других вариантов нет. Все полумеры сводятся к тому, что процесс внедрения стопорится и ломается.
Поэтому я еще раз хочу отметить важной правильной информационной политики. Только она способна уменьшить негативные эмоции персонала, неизбежно возникающие при внедрении чего-то нового и не привести к необходимости пункта б).
Ответственный за внедрение чего-либо должен иметь:
а) Понимание (целей, проблем и способов решения)
б) Желание
в) Полномочия
г) Определенная свобода действий и решений
д) Команду
Было бы неплохо еще и мотивацию иметь. Если Вы назначаете какого-то руководителя, вешаете ему на голову весьма нелегкую ношу, далеко не каждый будет готов работать на все 146% за ту же самую зарплату. Ведь можно отказаться, или согласиться, но ничего не делать - зарплата от этого не меняется.
Мотивация может быть двух видов - негативная ("уволим тебя, если не справишься") и позитивная ("добьешься этого - получишь премию", "заработает вот это - еще одну").
Когда меня предложили в качестве "координатора" от пилотов моей компании в начальном этапе внедрения, у меня все было нормально с пп. а) и б), в принципе неплохо с д), абсолютно никак с в) и полное "г" с г).
Соответственно, начав бурную деятельность по помощи своим коллегам-не-пилотам, я очень быстро стал получать по голове от тех, кто был не очень-то и заинтересован в изменениях. Так как это было мои непосредственные начальники, то у меня начался разрыв мозга - "мне дали задачу - мне связали руки". Я писал об этом периоде подробнее в предыстории к поездке в Qatar (см. часть первую сей саги).
Неудивительно, что я с радостью воспользовался возможностью послать все это куда подальше и покинуть офис, вернуться в обычные инструкторы. Повторное мое приглашение во внедрение состоялось через полтора года, когда сменилось руководство, и вернулся я уже на своих условиях. У меня появились кое-какие полномочия и достаточно большая свобода действий, я увидел, что к моему мнению прислушиваются на очень высоком уровне, и все это служило неплохой мотивацией и, как итог, пошло на пользу дела.
Так что, если Вы руководитель - то (считая, что информационное поле Вы уже сотворили) дело за малым. Собирайте команду внедрителей, при этом "заслуженность" того или иного руководителя не должна играть значимой роли.
В идеале, команда должна состоять из:
а) Мудрого руководителя, знающего цели, проблемы и решения, который будет направлять исполнителей и обеспечивать административный ресурс;
б) Летных специалистов. Практиков, хорошо разбирающихся в тонкостях планирования летной работы согласно существующим правилам. Они будут выступать консультантами.
в) Специалистов, имеющих хороший опыт работы в AIMS (лучший вариант), другими подобными системами, либо просто людей с хорошо работающими мозгами. С развитой логикой и умением схватывать на лету. Они будут настраивать правила.
г) Помощников, уверенно работающих с компьютером. Они будут рабочей силой - изо дня в день проверять на практике те правила, которые разработали первые трое.
Обязательным условием является наличие уверенного английского языка - ведь наверняка Вы, как руководитель, примете мудрое решение организовать рабочую поездку туда, где все это уже работает. Например, в Qatar или Air Berlin. Конечно, теперь Вам будет проще - Вы можете организовать рабочую поездку и в S7 Airlines, но все равно придется очень много общаться с разработчиками программного продукта, так что английский must have.
Теперь внимание, вопрос - с какой планеты я упал?
Как в отдельно взятой компании набрать таких мастеров-специалистов? Да никак. Вам очень сильно повезет, если хотя бы один из четырех пунктов будет исполнен. Безумно повезет, если в одном лице Вы найдете универсала. И просто фантастически повезет, если при всем при этом хотя бы треть будет знать английский на приличном уровне.
Таковы наши обычные реалии, не правда ли?
Есть, правда, один лайфхак по пунктам в) и г). Можно перекупить специалистов, имеющих хороший опыт администрирования AIMS и обладающих хорошими практическими навыками. Так делают многие зарубежные компании, приступающие к внедрению... Но мы решили так не делать и обойтись своими силами, тем более, что вариантов с набором соотечественников, обладающих требуемой квалификацией просто не существовало на тот момент. Был вариант заключить контракт непосредственно с AIMS'ом, но ценник специалиста в этом случае просто неприлично конский. Мы решили учиться сами, периодически запрашивая консультации у AIMS.
Конечно же, AIMS обеспечивает учебу для работы со своим программным продуктом. Но за тот срок сложно выучить все нюансы и тонкости, да и сами ребята из AIMS шутят, что "если кто скажет, что знает AIMS полностью, его надо срочно увольнять, т.к. никто не может знать AIMS полностью!"
Если у Вас большой запас оптимизма, времени и стальных нервов - то Вы можете сделать точно так же. Это должно рано или поздно сработать, но если у Вас есть много-много денег, Вы добьетесь результата за более короткий период времени, купив опытных специалистов или пригласив на несколько месяцев парня (или девушку) из AIMS.
Подытожим:
1. PR акции по освещению предстоящих изменений
2. Тщательный выбор ответственного персонала
3. Диктатура приоритета внедрения над всеми старыми хотелками.
И мотивация, мотивация, мотивация.
Если Вы это настроите, то все следующие проблемы решатся гораздо быстрее.
3. Готовность к революции.
Я не зря начал эту Сагу об AIMS с рассказов о багаже старых правил. Они несовместимы с зарубежными системами управления авиакомпанией.
Вы просто не сможете планировать "поэскадрильно", т.к. система не понимает такого понятия, как "zakreplennyi ekipazh". Это чисто советское изобретение, вносящее значительные сложности в планирование - если этому правилу следовать строго и без формализма, то в современном авиабизнесе выполнение рейсов компанией очень быстро прекратится, к тому же, с т.з. развития вредных "традиций" внутри замкнутых коллективов это еще и небезопасно. Поэтому за рубежом так никто не работает. Я писал уже об этом, повторяться не буду. Либо Вы готовы (и строите подготоку без формализма, о чем пойдет речь ниже), либо не начинаете внедрять AIMS, покупаете Авиабит или аналогичный продукт, заточенный "под русскую душу" и еще ..цать лет работаете по РОЛР ГА.
Чуть позже я подробнее раскрою эту тему, а теперь несколько советов по практическим проблемам
4. Практические проблемы
О практических проблемах можно не одну лекцию рассказать. Так что я ограничусь основополагающими.
База данных
Первая большая проблема - это создать ее. Вторая - поддерживать в актуальном виде.
Вторая проблема является вечной, но решается проще - актуальность обеспечивается автоматическим обновлением тех данных, которые умеют обновляться автоматически. Это запланированные проверки, медицина, учебы и т.п. - по умолчанию принят принцип "все все проходят". Соответственно, это позволяет системе обеспечивать автоматическое планирование работы в долгосрочном периоде, не спотыкаясь об ограничители.
Безусловно, для того, чтобы не допустить в рейс пилота, не прошедшего тот или иной вид проверки (учебы, ВЛЭК), от Вас требуется разработать процедуру оповещения специалистов по планированию в том случае, когда пилот "не смог".
Например, если я ставлю кому-то FAIL на тренажере, я обязан сразу же позвонить в "трекинг" и сообщить об этом. А уж потом могу звонить в летную службу.
Другие данные, не умеющие обновляться автоматически, поддерживаются специально наученными людьми, относящимися к летной службе (не пилотами, конечно же) по специально разработанной инструкции. У бортпроводников тоже есть такие специалисты.
Создание первичной БД - вот это та еще задача. На создание точной базы данных у нас ушло много времени и сил. Сначала мы сами точно не знали - какие именно данные нам потребуются. Поэтому списки ширились, и каждый раз девочки (помощницы командиров АЭ) должны были заново и заново лопатить тучи личных летных документов. При этом непременно возникали ошибки. Актуализация поступающих данных не проводилась (т.к. система еще не была полностью настроена - данные должны были обновляться вручную), либо проводилась с опозданием.
Пришлось делать несколько аудитов в течение короткого времени - кропотливый ручной труд помощниц КАЭ. Если представить, что они были уверены, что с внедрением AIMS их должности сократят, а их уволят - надо признать их работу героической и жертвенной.
Так же, пришлось обязать комэсок валидировать каждый суточный план пилотов на поиск ошибок, которые выдавала система и искать причины этих ошибок. Надеясь на их сознательность, конечно же.
По мере улучшения настроек системы (некоторые данные стали обновляться по факту исполнения запланированных событий), после проведенных аудитов, БД стала более-менее похожа на правдоподобную. Правда, еще не один аудит потребовался, что признать сей факт свершившимся.
Правила
Все предельно просто и архисложно одновременно. "Просто" - потому, что философия проста и понятна. "Сложно" - требует очень много настроек.
Система работает на Правилах, использующих информацию из Базы Данных, которая обязана в каждый момент времени быть актуальной.
В настройках Системы просто огромное количество всевозможных Правил планирования - на долгосрочном этапе, на краткосрочном этапе! "А что будет, если..?", или "а если не так, то так". Настраиваются рейсы, аэропорты, страны...
Правильно настроенные правила (включая учебы, ВЛЭК и прочее) позволяют правильно оценивать потребности в экипажах и, соответственно, не держать лишний штат, либо проводить наборы специалистов для того, чтобы... все правила работали.
Правила питаются "допусками". Под допуском в данном контексте я понимаю довольно многое - это и личные допуски, как пилота (минимум для посадки, возможность использования КВС на правом кресле, ETOPS, модификация ВС), так и информация о сроках действия сертификатах, документах (уровень языка, наличие визы, загранпаспорта). Пилотов, имеющие те или иные одинаковые свойства (например, свыше 60 лет, или имеющих ограничения по здоровью и все такое прочее), определяют в т.н. "категории", которые сам и создаешь под нужды своего планирования.
А дальше ты можешь настроить Правила, в которых укажешь, к примеру "для планирования рейсов на аэропорты, принадлежащие к данной группе (да-да, аэропорты тоже надо настраивать и сортировать!) использовать пилотов из категории номер такой-то".
Или же, ты хочешь, чтобы молодые КВС не летали с молодыми ВП (имеется в виду опыт). Значит, определяешь критерий для "молодых" КВС и ВП, определяешь таковым соответствующие категории. Затем настраиваешь правило "Запрещается планирование КВС категории такой-то с ВП категорией такой-то".
Далее дело за малым - специалисты по поддержанию Базы Данных по инструкции открывают или закрывают соответствующие категории. Под "открытием" подразумевается указание даты действия. Под "закрытием" - указанием даты, когда данное свойство у пилота отменяется. Правила оперируют периодом планирования, сверяя его со сроком действия категории.
Итак, очень много данных. Очень много правил. Правила базируются на данных. Закон - данные должны быть актуальны.
И правдивы. Система - наивная доверчивая девушка. Она верит мужикам на слово. Если ты ей сказал:"Вася Пупкин - инструктор", значит для нее Вася Пупкин такой же инструктор, как и все остальные, и неважно, что ты, как комэска, привык Васю Пупкина использовать исключительно для формализации "провозок", и никогда - для ввода в строй. Будь спокоен, именно Васю Пупкина она и назначит на ввод в строй самого бестолкового студента во исполнение Закона о Бутерброде.
Правила могут иметь два уровня "твердости". Одно - "твердое" (hard, если быть точным), нарушение которого трактуется однозначно как нарушение. Обычно это правила, основанные на требованиях государственных документов. Второй - "мягкое" (soft), которое в обычных условиях следует соблюдать, но иногда допустимо нарушить - c т.з. законов и нормативных актов оно при этом не будет нарушением. Обычно это правила компании, во имя тех или иных целей дополняющих требования государства, т.е., устанавливающие некий зазор между "мягким" и "твердым".
Например, государство говорит, что минимальный отдых между полетными сменами на базе - 12 часов. Это жесткое правило. Компания говорит - ОК, я буду стараться планировать минимальный отдых не менее 15 часов (soft), но если война и немцы (лицо КЛС отказалось от рейса, т.к. уехало на рыбалку и надо найти ему замену среди тех, кому не повезёт), то можно и 12 (hard).
Сразу настроить все правила невозможно, т.к. по мере работы растет опыт, растет понимание, поэтому правила - это то, что подвержено перенастройкам. Удалениям и добавлениям.
Вообще, забавная штука - правила. Ты хочешь сделать их идеальными и справедливыми для пилотов... и система не покрывает большинство рейсов, т.к. при таких настройках сетка в решете становится слишком мелкой. Командир АЭ возмущается - мол, у меня руками лучше получалось планировать. Начинаешь искать правду - выясняется, то ни фига. Льстит себе - в таких же случаях он шел на "расширение сеточки". И, конечно же, план закрывал. А у Системы нет возможности самостоятельно сеточку расширять.
Поэтому, ребята, садимся снова думать над правилами. Делаем их более гибкими для планирования.
Не старайтесь начать с создания идеальных (как вам представляется) правил! Начните с минимальных ограничений, чтобы научиться планировать. А затем потихоньку идите в сторону улучшения сатисфакции от планирования. Летный состав, конечно же, будет высказывать свое "фи" планированием - но Вы ведь провели правильную информационную политику, не правда ли?
Внешнее влияние на планирование
Многие компании погорели на том, что позволяли влиять на планирование "заслуженным" и не очень пилотам, которые ничтоже сумнящеся входили в контакт с "девочками из планирования" и те исполняли их хотелки - как личные, так и направленные на других, не отличавшиеся объективностью.
Мы сразу же стали жестко отсекать любые контакты рядовых пилотов с планированием (к ним вообще зайти можно лишь по специальному магнитному пропуску), поэтому проблему личных запросов победили довольно быстро. Однако, с другой проблемой справлялись очень долго. Ведь комэски далеко не сразу смирились с тем, что у них отобрали привычный инструмент управления пилотами. А особо продвинутые пилоты быстро просекли, что через штаб можно присылать указания по планированию от имени своего начальника.
Достаточно долго привычной картиной было получение отделом планирования сотен писем и предложений (в сумме от обеих компаний) в течение активного периода планирования следующего месяца. Это очень сильно мешало планированию, т.к. во многих случаях благие намерения вызывали нарушения в планировании, т.к. комэски не очень утруждали себя сверкой своих предложений со всеми правилами. А каждое предложение ведь надо было проверить - все ж начальник звонит/пишет.
Во время своего "второго прихода в офис" это стало одной из первых задач, которую я постарался решить. Были определены лица, имеющие право личного доступа в отдел планирования. Определены четкие правила, по которым можно заказывать события на следующий период планирования. Определен способ поступления данной информации в отдел планирования.
То есть, вопрос был решен процедурно и немного административно - пришлось провести несколько жестких бесед, в т.ч. с "заслуженными" и "уважаемыми".
Поток писем от летчиков и даже КЛС Глобуса в отдел планирования сократился значительно (первый вообще упал до нуля). Влияние на планирование уменьшилось. Процесс планирования значительно упростился и ускорился.
5. Искоренение формализма
Система НЕ понимает формализм!
Она НЕ оперирует абстрактными понятиями типа: "Ну ладно, я поставлю ему этот допуск, но никогда в Норильск одного, без инструктора, его не пущу". Либо он может летать в Норильск, либо нет. 1 или 0. True или False.
Для жеского правила "допуск" иных цифр нет.
С советских времен комэски в своей голове всегда держали тучу неформальных правил планирования. Только они знали - кого можно куда и с кем планировать, а кого нет. При этом они мало внимания обращали на фактическое соответствие тех или иных допусков способностям пилота - они были уверены, что если приспичит, то они поставят его либо с сильным ВП (или КВС, если речь о ВП), либо с инструктором. Либо, если никак совсем, а лететь надо, то "один раз не фантомас".
Стоит понимать, что проработав в подобном ключе не один десяток лет, мозги перестроить на новый лад практически невозможно.
Теоретически, все эти неформальные правила можно вбить в Систему. Но только она перестанет планировать примерно с третьего дня месяца, т.к. заткнется на каком-либо противоречии, которое постесняется решить методом "один раз не фантомас".
Так что договоримся об одном - Вы либо решаете навсегда отказаться от привычного формализма в оценках способностей своих пилотов ("ну поставь ему допуск, а я закреплю его с Ивановым - тот до ума доведет" - все, этого нет, умерло) - либо вступаете на зыбкую дорожку, могущую привезти в тесную комнату с небом в клеточку. Даже так.
Соответственно, очень важно проводить мероприятия по повышению качества профессиональной подготовки всего летного состава, начиная с экзаменаторов и инструкторов. Вот такая она штука - внедрение систем западного образца. Это не просто перевод с бумаги на экран, это качественное изменение всех процессов работы. Гораздо проще перестать заниматься формализмом, чем трястись над планом в поисках пилотов, запланированных таким образом, каким "я, будучи комэской никогда не спланировал!"
Итак, подытожим.
Вы приняли как должное, что для успешного внедрения подобной системы Вы должны быть готовы к изменениям - раз, и научиться работать без формализма в оценке пилотов и бортпроводников - два.
В противном случае Вы должны отказаться от автоматического процесса планирования и использовать Систему лишь как дорогую замену карандашу и резинке. Насколько я в курсе, так используют российский Авиабит в некоторых компаниях, где все еще пытаются создать видимость следования правилам РОЛР ГА-87 - комэски корпят над бумажным планом, а в конце рабочего дня помощницы маникюром забивают его в Систему. Да чего тут говорить, если в одной крупной компании таким образом используют дорогущий Jeppesen, умеющий творить чудеса при автоматическом планировании!
Предположим, что Вы смелый и решились на Революцию. Соответственно, теперь Вы работаете не только над настройками системы, но одновременно у Вас открылись новые направления:
1. Создание новых правил организации летной работы
2. Создание новых программ подготовки.
6. Новые направления творчества
Тут открывается простор для творческой мысли. По пункту один могу сказать, что мы "перекрасились" и ушли от авиационных эскадрилий. Хотя структура все еще похожая, однако, изменились функции летных руководителей начального и среднего уровня. Мы планомерно перепрофилируем их с планирования на профподготовку. Пилоты поделены на летные группы, у каждой ЛГ есть "шеф", который отвечает за дисциплины и профессиональную подготовку. Мини-комэска, но только с отобранным карандашом и резинкой.
Конечно же, планирование рейсов не учитывает принадлежность пилотов к той или иной группе. Каждый летает с каждым насколько позволяют правила, заложенные в систему и свойства каждого пилота, туда же внесенные.
По пункту два могу дать совет - прежде чем вносить в систему все, что связано с подготовкой пилота, надо сесть за документы и выписать все подряд - что специалист должен иметь для допуска к пилотам. Составить подробную таблицу, чтобы потом можно было ее сводить в программы подготовки.
Очень большое внимание требуется уделить тренажерной подготовке и тому, что ФАП 128 требует от нее. Так же, подумать над возможностью использования тренажерного времени для исполнения некоторых положений ФАП 147.
Далее, не стоит забывать о таких мелочах, как инструктажи по охране труда, пожарной или электробезопасности. Это все тоже требуется проводить, и в случае чего будет спрос. Это все тоже можно и нужно планировать.
7. Документирование процедур и написание инструкций
До поры до времени процесс работает на "понятиях". При внедрении так даже удобно - ведь сложно написать сразу документ "с листа", представляя предмет лишь в воображении. Иногда проще сначала потыкать кнопки и понабиывать шишки, нащупать правильное направление и проработать его. Не возбраняется обсуждать все эти шишечки на совещаниях и протоколировать найденные решения.
Но однажды наступает момент, когда протоколов становится больше, чем ящик в столе. Часть из них уже потеряла актуальность, а часть просто потерялась и передается, как предание от одного специалиста к другому. Чтобы не доводить до этого, надо своевременно приступать к описанию процедур в соответствующем документе.
Писать надо очень и очень много - это и описание правил работы с AIMS, это и описание стандартных процедур планирования. Инструкции на рабочем месте.. И бла-бла-бла многое другое.
Если судить о том, что данную запись я сочинил из головы менее, чем за два часа, можно представить, что мне это немножко проще, чем другим :) Поэтому я так же занимаюсь тем, что вместо секретарши (которой у меня и нет) печатаю стандарты :)
Очень важно - писать не "на отзовись", а по делу. Документ должен быть рабочим, а не просто для того, чтобы отчитаться перед руководством "Да, мы написали тот стандарт, который Вы ждали от нас в прошлом году".
Соответственно, если документ влияет на правила планирования, то он должен выходить таким образом, чтобы не конфликтовать с уже запланированным ростером. Т.е., ревизия должна начинать действовать в будущем периоде, на который планирование еще не осуществлено. И, конечно же, любое правило, влияющее на планирование, должно в первую очередь пройти согласование со специалистами по планированию. Иначе потом будет прикольно - правило не ложится на Систему, или рушит что-то еще. Сроки других подготовок, например.
Конечно же, если положения одного документа используются положением другого, который в свою очередь непосредственно используется при планировании, то ревизии данных документов должны выходить в свет одновременно. И вступать в силу в будущем периоде, на который планирование еще не осуществлено.
Представляете, сколько всего надо сделать в документах, чтобы красиво планировать? А теперь умножьте это на два по количеству зеленых авиакомпаний, и представьте проблемы, которые возникают при планировании, если правила планирования в двух компаниях различаются? Например, потому что, в первой компании программы подготовки вышли в июле, а во второй соответствующие изменения произошли в сентябре. А настройки Системы используются одни и те же. Да, в планировании знают, что во второй компании будут такие же правила, но юридически пока действуют старые...
Данную проблему можно решить процедурно. Этим, к слову, я тоже занимаюсь, т.к. громче всех ее в свое время озвучил :)))) Шучу, я сам вызвался, т.к. без решения ее двигаться дальше бесполезно. Это стало очередным вызовом.
- - - -
Вот такая интересная штука - AIMS. Хотели вроде как экипажи автоматически планировать, а в итоге перешерстили почти все рабочие процессы и подняли их на новый уровень. Вот почему я все еще сохраняю мотивацию летать на В737 именно в этой авиакомпании, при очень розовой мечте о большом самолете - мне интересно участвовать в процессе, и интересно посмотреть, чем все это закончится.
Хотя можно предположить, что никогда не закончится, т.к. вступив на тропу Революции, это становится заразным.
В дальнейшем я планирую поделиться опытом внедрения модуля планирования тренировок и рассказать о рабочей поездке в Афины, что состоялась еще в декабре.
Удачных инноваций!
Journal information