С пометкой срочно как пишется

Однако на практике все еще встречаются примеры, достойные занесения в книгу рекордов бюрократии.
Сегодня, выражаясь канцелярским языком, в определенных кругах пошла мода едва ли не всякое письмо помечать грифом “Срочно” или “Весьма срочно”, что, наверное, по здравому рассуждению отправителей должно внушать всем получателям благоговейный трепет, придавать им необходимое ускорение и вызывать необычайный прилив старания. Иными словами, все другие дела — в сторону…
26 марта Министерство образования разослало в облисполкомы и Мингорисполком с пометкой “Срочно” текст, озаглавленный следующим образом: “О согласовании Положения о классах с изучением специального учебного предмета спортивной направленности в общеобразовательных учреждениях”. Тема, безусловно, актуальная. Спорту государство уделяет пристальное внимание, и очень правильно, что серьезные решения перед утверждением проходят процедуру тщательного обсуждения. Именно так логичнее всего было бы объяснить действия уважаемого министерства. В противном случае: зачем присылать? Если только, конечно, под согласованием не подразумевается механическое проставление подписи должностного лица. А именно на такие размышления наводит последняя строчка письма: “Просим утвердить представленный проект постановления не позднее 17 часов 26 марта 2008 г.”. То есть времени для вникания в положение с “приложением на 10 л.” в исполкомах по большому счету не оставалось. Пока получили, зарегистрировали, определили исполнителя, сходили за резолюцией к руководству, отправили на рассмотрение — тут уже пора и ответ давать. Так нужно ли стольких людей отрывать от работы, когда надо лишь “утверждение”? Да и что за спешка в вопросе о спортивных классах?
Но Министерство торговли пошло еще дальше. Оно свою “депешу” в “республиканские органы государственного управления, иные организации, подчиненные правительству Республики Беларусь, облисполкомы и Мингорисполком” снабдило более грозным словосочетанием “Весьма срочно!” Что же заставило Минторг прибегнуть к столь резкому призыву? Оказывается, “поручение Совета Министров Республики Беларусь от 27 февраля 2008 года № 35/205-391 о подготовке совместно с облисполкомами и Минским горисполкомом перспективных предложений (концепций) по созданию розничной торговой сети в Санкт-Петербурге (до 50 торговых точек) для реализации белорусской продовольственной продукции”. Министерство же торговли дало на осмысление местным властям считанные часы. А ведь выработка предложений по расширению товарооборота требует кропотливой работы, причем не одного дня. Без сомнения, такая работа будет проведена (или уже проведена), только вот с подобной перепиской она имеет весьма опосредованную связь.
Министерство архитектуры тоже не особо пожаловало Минэкономики, Минфин, Министерство по налогам и сборам, Минюст, Мингорисполком, облисполкомы, когда разослало им проект готовящегося к подписанию документа о “некоторых вопросах исчисления и использования части прибыли организаций по производству цемента” с просьбой “согласовать в срок не позднее 10.00 12.03.2008. В случае наличия замечаний просим прибыть на согласительное совещание в Минстройархитектуры к 12.00 12 марта 2008 года”. Заметьте, в самом Минстройархитектуры сей образчик деловой переписки был зарегистрирован 11 марта, а к адресатам поступил 12 марта утром, а в 10 часов надо было уже выслать ответ, а если кто-то имеет что-то против, то милости просим к нам в полдень. Можете себе представить, что, допустим, в Гродненском или Могилевском облисполкоме все же не полностью разделяют позицию министерства. И что делать? Бросать все дела, лететь на вокзал в надежде вскочить в ближайший поезд на Минск? Но в Минск при данном цейтноте можно успеть только на самолете. Личный самолет на взлетную полосу!.. Но нужно отдать все же должное министерству. Там, видимо, осознав, что погорячились, разослали после обеда
12 марта новое уведомление, где просили согласовать проект до 14 марта. А если, к примеру, из Брестского облисполкома уже в столицу “снарядили отряд”? Отзывать с полдороги?
Но грамотнее всего поступил Минсельхозпрод. 27 декабря 2007 года он зарегистрировал у себя документ № 03-1-11/14336, где просил облисполкомы согласовать проект постановления Совмина с приложением на 126 листах до 13 часов 28 декабря. Представляете: 126 страниц и времени в обрез! Зачитаться можно. Но и это еще не все. Письмо пришло 3 января 2008 года. Может, почта виновата, а может, отправить забыли… Но суть в другом: зачем эти нереальные сроки? Вот запрос вообще затерялся — и ничего, мир не рухнул.
Подобных примеров не совсем деловой переписки воз и несчетное количество тележек. Но заставляет задуматься не только содержание написанного, но и количество отправленного. В Гомельском облисполкоме мне сказали, что лишь за два месяца нынешнего года рост поступающей корреспонденции составил почти 30 процентов. Пустяк, ничего особенного? Но бумажный и электронный вал, как вирус, может в конечном итоге привести к сбою системы управления. К тому же подобные “опусы” нивелируют значение самой переписки, сводя ее роль к сугубо механическим действиям, когда отправителя, по сути, не интересует чье-либо мнение, кроме своего. Это похоже на бюрократический ритуал, а не на стремление принять взвешенное решение. К тому же подобные творения забирают много времени, вынуждая десятки людей заниматься бумажной рутиной, а не реальными делами. Между тем как время — деньги.
Идущая на государственном уровне борьба с проявлениями бюрократизма имеет важную основу — освободить служащих от ненужных обязанностей и использовать появившуюся временную “форточку” на то, что важно. В противном случае получается только иллюзия деятельности. То есть какой-нибудь старательный завотделом минутки свободной не имеет, а результата осязаемого нет. И вот эту ситуацию действительно нужно исправлять “СРОЧНО” или даже “ВЕСЬМА СРОЧНО!”.

Заметили ошибку? Пожалуйста, выделите её и нажмите Ctrl+Enter

В чем ценность Low-code

Начнем с ключевой ценности Low-code для бизнеса – ускорения создания корпоративных приложений.

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

Low-code BPM позволяет разрешить эту ситуацию и выровнять ее. Это значит, что корпоративные приложения теперь создаются достаточно быстро, и очередь из потребностей бизнеса в автоматизации не формируется. Эту ценность сложно переоценить, потому что внешняя среда меняется крайне стремительно, всем нужна ускоренная автоматизация.

Еще одна важная мысль, которую стоит иметь в виду – сравнение подходов к автоматизации. Не секрет, что автоматизировать тот или иной бизнес-процесс или деятельность компании можно разными способами:

• Внедрение коробочного решения. Это значит, что покупается коробочное решение, которое затем настраивается за минимальное количество времени. Здесь можно говорить о низкой стоимости владения и быстрых сроках автоматизации, но у коробочных решений есть один фатальный недостаток – это усредненный функционал. Такой функционал, как правило, использует большинство компаний и, таким образом, они становятся похожи. Уникальные бизнес-процессы компании внутри коробки просто невозможно реализовать. Многих такое положение дел не устраивает, потому что именно в уникальных бизнес-процессах кроются конкурентные преимущества.
• Самостоятельная разработка. В этом случае компания сама разрабатывает корпоративное приложение. Так же к самостоятельной разработке можно отнести адаптацию под себя ERP-систем – SAP, 1С и др. Самостоятельная разработка считается дорогой, потому что необходимо держать большое количество ИТ-специалистов и разработчиков в штате. Автоматизация в этом случае может занимать годы.
• Применение Low-code BPM-системы. Стоимость разработки в этом случае снижается многократно, и высококвалифицированные штатные специалисты не нужны. Low-code – это про быструю автоматизацию.

Чем традиционная разработка отличается от Low-code подхода

Давайте сравним традиционный подход к разработке с Low-code подходом. Для этого посмотрим на стандартный процесс разработки, который состоит из 5-ти шагов:
1) формирование требований
2) разработка
3) стабилизация
4) развертывание
5) эксплуатация и поддержка

Далее расшифруем каждый из шагов:

• Формирование требований: На этом шаге пишется техническое задание на внешний или внутренний проект. Аналитики работают с бизнес-заказчиками и переводят язык бизнеса на формальный язык ИТ.
• Разработка: Этап начинается после утверждения технического задания, которое затем передается разработчикам. Разработка – длительный и трудоемкий процесс, может занимать от нескольких месяцев до года и более.
• Стабилизация. Этот этап подразумевает тестирование системы представителями бизнеса. Бизнес-пользователи обживаются в новой ИТ-системе, проходят все сценарии ее использования и формируют фитбэк ИТ-специалистам.
• Развертывание: на этом этапе тестирование завершено, и необходимо обновить текущую информационную систему, либо развернуть совершенно новую систему на нашем продуктивном ландшафте. Это по сути накатывание ИТ-системы на сервера, ее развертывание и массовое подключение пользователей.
• Эксплуатация и поддержка: корпоративное приложение находится в продуктивной среде, его нужно поддерживать с точки зрения всевозможных доработок, выделения вычислительных мощностей и обеспечения доступности в режиме 24/7 с заданными параметрами отклика.

Это 5 этапов классической разработки информационной системы в бизнесе. Далее рассмотрим каждый из этих этапов в отдельности и покажем, как они меняются при переходе на Low-code.

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

Задача аналитиков на этом этапе – написание качественного ТЗ. С этим, как правило, возникают сложности, поскольку информационной системы еще нет, и бизнес не может детально сформулировать свои требования. Аналитики вынуждены оставлять «белые пятна» в техническом задании с пометкой «бизнес формализует требования по ходу проекта».

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

Low-code принципиально меняет ситуацию. При применении Low-code-инструментария ТЗ практически не пишется – оно заменяется подготовкой прототипа. Такой прототип может быть собран за несколько рабочих дней и представляет собой MVP, который можно обсуждать с бизнесом. Все требования заказчика – кнопки, настройка интерфейсов, бизнес-логика – прорабатываются на прототипе в режиме реального времени. Таким образом, заказчику становится легче формулировать требования, потому что можно сразу увидеть, как будет выглядеть конечный продукт.

Low-code кардинально трансформирует этап формирования требований – ускоряет, делает его гибким и понятным бизнес-заказчику благодаря прототипу. Кроме того, прототип на Low-code может сформировать даже начинающий аналитик, что позволяет грамотно распределять нагрузку внутри команды.

Этап разработка — самый трудоемкий из всего цикла создания корпоративного приложения. В классическом подходе команда получает техническое задание и далее разрабатывает информационную систему с нуля или на базе ERP-системы.
Часто бывает такое, что в командах разработчиков происходит ротация. Это значит, что если разработчик срочно понадобился на проекте «В», он снимается с проекта «А». Смена состава команды удлиняет разработку.
И, конечно, те самые «белые пятна», которые были оставлены аналитиками при формировании ТЗ, начинают влиять на процесс разработки и сроки.

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

Как выглядит подход с точки зрения Low-code: меняются требования к команде разработчиков, кодирования становится меньше. Более того, Low-code BPM соответствует Agile подходу в разработке. Это значит, что можно двигаться спринтами с детализацией требований по месту, и при этом иметь работающее корпоративное приложение — в рамках спринтов происходит усложнение разрабатываемого приложения.

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

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

С чем в этом случае может столкнуться тестовая группа пользователей и сами разработчики?

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

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

Стабилизация с помощью Low-code проходит гораздо проще и быстрее. Необходимые изменения в корпоративное приложение можно вносить в режиме реального времени при встрече с заказчиком.

Развертывание на продуктивных серверах предполагает массовое подключение пользователей к системе. Это происходит после того, как завершена тестовая эксплуатация и система принята тестовой группой пользователей.

Обновление продуктивной среды — это сложная процедура, которая подразумевает регламенты управления обновлениями и изменениями.

Запуск нового приложения сопряжен с рисками, связанными с текущим ИТ-ландшафтом, интеграцией системы с другими системами.

Low-code BPM облегчает процедуру развертывания. Например, в ELMA365 Low-code BPM реализована архитектурная изоляция приложений. Это значит, что при обновлении приложения или целого раздела целостность системы не теряется, и информационная система работает без сбоев. Более того, обновление отдельного приложения происходит в режиме реального времени и не подразумевает остановку системы.

Традиционно Low-code BPM подразумевает разделение сред разработки, тестирования, продуктивной эксплуатации и автоматизированный перенос отдельных приложений между этими средами.

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

Вновь обратимся к примеру ELMA365 Low-code BPM — она использует микросервисную архитектуру. Это дает возможность «упаковать» отдельные микросервисы в контейнеры (Docker), а использование платформы Kubernetes дает непревзойденную гибкость управления вычислительными мощностями.

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

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