Обеспечить коммуникацию и как наладить эффективную коммуникацию между сервисами

Допустим, что обязанности подчинённых в рамках проекта мы с вами распределили, пошла работа. Но – опять не всё «слава Богу».

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

Это могут быть как неучтённые на предварительной стадии препятствия, так и просто новые факторы, которые требуют рассмотрения, дополнительной информации, а то и – внесения коррекций в изначальную диспозицию.

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

Вывод: сотрудникам необходим контакт с руководителем, и лучше бы, чтобы это проходило как-то организованно.

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

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

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

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

Если ваши подчинённые обладают высоким уровнем исполнительской дисциплины, то задача несколько упрощается. По завершении процесса распределения обязанностей достаточно было бы договориться о том, что при столкновении с любым препятствием и/или неожиданным фактором они немедленно сигнализируют об этом вам. Но – и об этом надо не забыть договориться.

Кроме того, советую приготовиться к тому, что кто-нибудь из тех подчинённых, кто обладает несколько большим хитроумием, попытается использовать предоставленную возможность для того, чтобы «перепихнуть» часть распределённых ему обязанностей обратно руководителю.

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

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

Возможно и даже весьма вероятно, что причины такому положению дел будут самыми, что ни на есть, объективными. Правда – вопрос, насколько это может служить сильным утешением. Методы и интенсивность контроля в немалой степени зависит от квалификации и дисциплинированности подчинённых, а, кроме того – от характеристик рабочей задачи.

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

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

Не существует информационных систем, которые в одиночку могли бы покрыть потребности современного предприятия. Средние и крупные организации обычно эксплуатируют как минимум десяток многопользовательских систем, а иногда счет идет на сотни и тысячи. В этих системах часто обрабатываются одинаковые данные — начиная со справочников и классификаторов. Обычны ситуации, когда в рамках одного бизнес-процесса задействованы разные информационные системы. Многие информационные системы изначально ориентированы на получение информации из других приложений и баз данных (например, системы формирования сводной и корпоративной отчетности, системы управления и мониторинга). Поэтому ни одно корпоративное приложение не может рассматриваться как нечто автономное, а всегда является частью большого механизма под названием «информационная система предприятия».

Следствиями отсутствие должного решения проблемы интеграции являются:

• повторный ручной ввод данных (справочники, данные об отгрузках, финансовые транзакции и т.п.);
• многократные и бесконечные «сверки и корректировки» не исключающие ошибок;
• непомерные затраты на формирование сводной отчетности;
• неприемлемые сроки и себестоимость выполнения даже обыденных задач.

Это определяет цели интеграции приложений предприятия.

Цели интеграции

Общие цели интеграции приложений можно сформулировать следующим образом:

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

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

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

Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Автор, выступая в качестве исполнителя работ, сталкивался с разными вариантами «спонсорства» таких проектов. Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Однако для интеграционных проектов такая заинтересованность жизненно необходима. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т.д. Согласование и формализация требований разных подразделений становится очень трудной задачей; отсутствие среди «идеологических лидеров» проекта человека, которому подотчетны все задействованные подразделения, обычно означает провал проекта. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния.

Не надо забывать, что основная цель интеграционных проектов — снижение издержек, равно как и предпосылки к проектам лежат в бизнес-области даже если проект относится сугубо к ИТ. К примеру, задача развертывания систем управления и мониторинга возникает, если бизнес озабочен снижением затрат на эксплуатацию ИТ-инфраструктуры. Мало того, интеграционные проекты в какой-то степени являются перекладыванием проблем с бизнес-подразделений на ИТ-службу. Рассмотрим, к примеру, типичную ситуацию, когда формированием отчетов «в стиле Excel» для руководства занимается группа в составе финансового департамента. От ИТ-подразделения при этом требуется лишь поддержание в работоспособном состоянии корпоративных информационных систем. В случае же внедрения системы, автоматически формирующей эту отчетность, за все — в том числе и за ошибки в данных — будет отвечать ИТ-служба. Действительно, по мере увеличения степени интегрированности и взаимосвязанности информационных систем возрастает ответственность, роль и статус ИТ-службы, увеличивается зависимость основных показателей работы всей организации от надежности и эффективности интегрированной информационной системы предприятия.

Взаимодействие интегрированных приложений

Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный обмен сообщениями. В этом списке нет прямого обмена данными между базами данных приложений: этот метод ближе не к интеграции приложений, а к перемещению данных. С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку (например, при загрузке накладных пересчитывать товарные остатки). Прямой обмен данными, который обычно выполняется средствами класса ETL (extract, transfer, load) или самодельными утилитами, обычно такой возможности не предоставляет.

Обмен файлами

Обмен файлами пожалуй, самый распространенный подход к организации взаимодействия. Это связано с относительной простотой реализации, а также существованием стандартных (или «почти» стандартных) форматов обмена. Например, большая часть корпоративных информационных систем позволяет загружать и выгружать файлы, например, в формате CSV (Comma-Separated Values — «поля, разделенные запятыми»). Но у этого подхода есть и недостатки; если необходимо оперировать сложными структурами, то простые форматы обмена уже не пригодны. Возникающие в таких случаях специализированные форматы файлов должны «понимать» взаимодействующие системы, что ведет к жесткой зависимости систем друг от друга. Этот недостаток обычно преодолевают всевозможными утилитами конвертации данных. Кроме того, обычно обмен файлами подразумевает участие человека — кто-то должен выгрузить файл, скопировать его на другой компьютер, загрузить. Однако если интегрируемые методом обмена файлами системы имеют возможность автоматической загрузки/выгрузки (например, по расписанию), то данный подход позволяет построить полностью автоматизированное решение, которое вследствие своей простоты обладает высокой надежностью и пропускной способностью.

Общая база данных

Данный подход концептуально очень прост — несколько информационных систем или приложений используют одну базу данных. Главный его недостаток — связь между интегрированными приложениями настолько тесная, что иногда невозможно заметить границу между ними (обычно так интегрируются продукты одного производителя). Примером такого подхода могут служить большинство ERP-систем, где различные модули системы используют одну базу. Однако слишком тесная связь превращает конгломерат интегрированных приложений в монолит, в «суперсистему», отдельные части которой с трудом поддаются самостоятельной модернизации и замене. С этим борются, используя механизмы серверов баз данных (представления данных, промежуточные таблицы и т.п.), но далеко не всегда эффективно.

Удаленный вызов

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

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

Асинхронный обмен сообщениями

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

Недостаток данного подхода — высокая цена. Система гарантированной доставки на основе очередей сообщений обычно сама по себе недешева; единственным известным мне исключением является Microsoft Message Queue (MSMQ), компонент серверных операционных систем семейства Windows. Правда, есть и свободно распространяемые бесплатные (например, ActiveMQ), которые, тем не менее, нужно развернуть, обучить специалистов, поддерживать, написать адаптеры между системой доставки и приложениями и т.д.

Топология

Существует два подхода к организации маршрутов взаимодействия интегрируемых системы. Первый — прямое взаимодействие интегрированных систем по принципу «каждая с каждой», или «точка-точка». Второй — взаимодействие через центральный узел; подобную звездообразную архитектуру обычно называемую «хаб + спицы». Топология не зависит от физической архитектуры информационной системы, а определяет логические маршруты взаимодействия и передачи данных между интегрированными системами.

Точка-точка

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

Если взаимодействующих приложений много, стоимость сопровождения интегрированной таким образом информационной системы предприятия становится неприемлемо высокой. Тем не менее подход «точка-точка» широко используется. Это происходит, как правило, в тех случаях, когда при взаимодействии конкретных приложений необходимо передавать большие объемы данных или обеспечивать нормированное время взаимодействия, а также если эксплуатируемые на предприятии приложения имеют встроенные средства взаимодействия (это часто случается при внедрении нескольких систем от одного поставщика, а также если при разработке заказных программных систем или внедрении новых к ним изначально предъявляется требование по взаимодействию с уже имеющимися системами).

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

Хаб + спицы

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

• организация маршрутизации взаимодействия между интегрированными приложениями;
• преобразование форматов файлов и данных;
• обеспечение взаимодействия приложений с использованием разных методов и протоколов взаимодействия.

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

Недостатком топологии «хаб + спицы» является высокая стоимость приобретения и сложность программного инструментария, играющего роль хаба, а также нехватка специалистов, имеющих опыт применения подобных программных средств.

Выбор средств интеграции

Готовых инструментов интеграции на рынке немало. Так, только корпорация IBM в разделе программного обеспечения интеграции приложений предлагает пару десятков групп продуктов и еще много интеграционных продуктов в других категориях. Сложность выбора состоит в том, что среди представленных средств есть и узко ориентированные (например, IBM Message Broker), и позиционируемые как «универсальные» (скажем, Microsoft BizTalk). Однако выбор того или иного инструментария определяется не тем, что о нем говорит производитель, а конкретным составом «зоопарка» аппаратно-программных решений в организации, которые необходимо заставить работать совместно.

Советы общего плана

Перед выбором программных средств интеграции необходимо четко определить все системы, нуждающиеся в координации или в обмене данными с другими системами; документировать все возможные протоколы взаимодействия, требования по объему данных, расписанию обмена и т.д. Ключевым моментом также является необходимость участия человека в процессе взаимодействия информационных систем. Часто это диктует выбор решений, не имеющих, на первый взгляд, отношения к интеграции.

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

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

Совет конкретный

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

Отдельно про Web-сервисы

Сегодня технология Web-сервисов позиционируется как удобное средство интеграции приложений, поскольку позволяет реализовывать, развертывать, и обеспечить простое межплатформное взаимодействие. К сожалению, наш опыт говорит о практической неприменимости современных технологий Web-сервисов для интеграции приложений как общего подхода. Действительно, пока Web-сервисы оказываются непригодны для обработки больших объемов информации; в них отсутствуют средства поддержки транзакций; взаимодействующие системы должны находиться в работоспособном состоянии на момент взаимодействия.

Непригодность к обработке больших объемов — врожденный недостаток, который связан с XML-природой Web-сервисов. Все данные и параметры вызовов Web-сервисов преобразуются в формат XML, что во много раз увеличивает объем данных со всеми вытекающими из этого последствиями в виде растущей потребности в оперативной памяти и нагрузки на процессоры. К сожалению, речь идет не о гигабайтах передаваемой информации: Web-сервисы «захлебываются», когда за одно взаимодействие между интегрированными системами нужно передавать уже сотню килобайт. (Правда, существует стандарт WS-Attachments, описывающий механизм подсоединения к вызовам Web-сервисов любых данных без перекодирования в XML, однако ведущие поставщики этот стандарт не поддерживают.)

Далее представьте, что в процессе взаимодействия множества информационных систем необходимо провести согласованные изменения в некоторых из них, то есть выполнить логическую транзакцию, затрагивающую несколько систем. Если для интеграции используются Web-сервисы, то такой возможности нет: в своем «исходном» варианте Web-сервисы не поддерживают заключение в рамки одной транзакции несколько вызовов методов одного или нескольких сервисов. Поставщики интеграционного программного обеспечения в этом случае обычно предлагают использовать так называемые «компенсационные операции» (на каждую операцию предусмотреть отменяющую ее операцию). Скажем, если из трех участвующих в логической транзакции приложений два смогли выполнить какую-то операцию, а одно — нет, то в двух системах нужно выполнить действия отката, отменяющие результат успешно выполненных операций. В теории подход хорош, но, во-первых, никто не гарантирует успех компенсационной операции, а во-вторых, некоторые системы (например, финансовые) не допускают удаления данных, внесенных в базу.

Предварительный стандарт WS-Transactions, призванный решить данную проблему, существует, но отсутствуют его полноценные реализации. Так, корпорация IBM заявила о поддержке этого стандарта в своих интеграционных продуктах, основанных на WebSphere Application Server, но с массой ограничений; самое главное из которых — все взаимодействующие Web-сервисы должны работать под управлением WebSphere Application Server. Аналогичная ситуация и у Microsoft в .Net 3.0, что выхолащивает смысл Web-сервисов — простоту межплатформного взаимодействия.

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

Немного о ESB и SOA

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

Подобный инструментарий промежуточного слоя стоил слишком дорого, а специалисты по нему — еще дороже. Когда появился новый метод межплатформного взаимодействия, Web-сервисы, родился и новый подход к организации основы для интеграции — сервисная шина предприятия (Enterprise Service Bus, ESB). Реальным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP. Основанный на ESB подход подавался как более дешевая, простая в реализации альтернатива предыдущей концепции.

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

Вокруг архитектуры, ориентированной на сервисы (Service-Oriented Architecture, SOA), также очень много маркетинговой шумихи. На мой взгляд, SOA — это не конкретные продукты и даже не технология, а лишь концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. Это означает, что для пользователей ничего не изменится, пока ведущие поставщики программного обеспечения (и прежде всего, производители бизнес-приложений наподобие ERP, CRM, EAM и т.д.) не модифицируют свои системы в соответствии с SOA. Только тогда можно получить реальный выигрыш; пока же популярные бизнес-приложения — это замкнутые системы с очень «узким» внешним интерфейсом.

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

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

Хотите наладить взаимодействие отделов, но не знаете, с чего начать? Наталья Колосова, директор департамента по работе с персоналом Xerox Евразия, делится практическими советами, проверенными на опыте компании.

Выявите потребность

Для начала важно понять, в каких случаях командная работа подразделений необходима, а в каких — не так нужна и не влияет на бизнес-результаты.

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

При этом в большинстве других случаев диалог лучше изоляции. Но как же его выстроить? Об этом мы и поговорим.

Подберите инструменты

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

Встречи с руководителями и сотрудниками

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

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

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

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

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

Культура проектной работы

Очень полезно объединять сотрудников из разных отделов для работы над общими проектами.

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

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

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

Внутренняя ротация персонала

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

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

Политика «открытых дверей»

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

В офисе компании

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

Внутренний информационный портал

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

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

Решите проблемы в коммуникациях

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

• Убедитесь, что коммуникация в компании выстроена максимально эффективно и проходит по цепочке от руководителей к подчиненным. Кажется, что делиться информацией — это несложная и очевидная задача каждого руководителя. Но практика показывает, что менеджеры часто смещают фокус в сторону решения бизнес-задач и относят на второй план обсуждение c командой целей, стратегии, планов и результатов работы компании. Такой подход стоит корректировать, ведь бизнес-результаты каждого отдельного сотрудника (или команды) напрямую зависят от того, насколько хорошо он понимает происходящее в компании.
• Взаимодействие подразделений может затрудняться из-за разницы в поведении разных поколений. Многие люди старшего возраста привыкли держаться обособленно и не обращаться к коллегам за помощью без крайней необходимости, в то время как молодое поколение иногда даже слишком активно вовлекается в коммуникации. Постарайтесь поощрять активность первых и направлять энергию вторых в правильное русло.
• Некоторые сотрудники не считают нужным обмениваться опытом и взаимодействовать с другими подразделениями. Обычно они объясняют это тем, что в их прямые обязанности не входят подобные задачи. Если вы сталкиваетесь с этой особенностью, постарайтесь вовлекать таких сотрудников в проекты и давать им больше информации о работе компании. Поощряйте участие в командных активностях и обращайте их внимание на то, как для них важно «быть в курсе» при выполнении рабочих задач.
• Встречаются и сотрудники, которые очень ревностно относятся к своей работе и отказываются делиться информацией с другими. Постарайтесь объяснить им, какую выгоду может принести обмен полезными для работы сведениями и почему это важно в масштабе компании и для профессионального развития. При этом учитывайте, что причина такой закрытости может быть связана как с личными особенностями сотрудника, так и с обрывом коммуникации со стороны его руководства.
• Многие компании намеренно поощряют соперничество между отделами, чтобы повысить эффективность их работы. Но практика показывает, что такой подход может привести к ненужным конфликтам, нежеланию делиться информацией и снижению эффективности работы. Поэтому вместо соперничества развивайте в компании соревновательный дух, побуждая отделы не «воевать» между собой, а вырываться вперед и достигать большего. При таком подходе у сотрудников будет больше мотивации и интереса к работе, и никто не окажется в положении проигравшего.

Общими усилиями к большим результатам

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

Материалы по теме:

Пост-миллениалы: как правильно работать с новым поколением сотрудников

Хотите переехать в виртуальный офис? Эти советы помогут вам организовать работу сотрудников

«Умные» бизнес-центры начнут массово строить в России уже через 10 лет»: как будут выглядеть офисы будущего

«Не каждого специалиста можно удержать высокой зарплатой»: как сделать так, чтобы сотрудники оставались надолго в компании

Как не сгореть на работе: почему неэффективны сотрудники, работающие на износ

Обеспечение взаимодействия в электронной форме участников внешнеторговой деятельности и иных лиц с органами государственной власти Российской Федерации, органами валютного контроля, уполномоченными Правительством Российской Федерации, и иными лицами в соответствии с их компетенцией с использованием информационной системы “Одно окно” в сфере внешнеторговой деятельности

1. Документы и информация, содержащиеся в информационной системе “Одно окно” в сфере внешнеторговой деятельности, используются в соответствии с законодательством Российской Федерации органами государственной власти Российской Федерации, органами валютного контроля, уполномоченными Правительством Российской Федерации, и иными лицами в соответствии с их компетенцией.

2. Обеспечение доступа участников внешнеторговой деятельности и иных лиц к информационной системе “Одно окно” в сфере внешнеторговой деятельности осуществляется оператором данной системы на добровольной и безвозмездной основе.

3. Доступ органов государственной власти Российской Федерации, органов валютного контроля, уполномоченных Правительством Российской Федерации, и иных лиц в соответствии с их компетенцией к документам и информации, содержащимся в информационной системе “Одно окно” в сфере внешнеторговой деятельности, осуществляется на безвозмездной основе.

4. Оператор информационной системы “Одно окно” в сфере внешнеторговой деятельности обязан обеспечить возможность использования содержащихся в информационной системе “Одно окно” в сфере внешнеторговой деятельности документов и информации на протяжении всего срока их хранения в соответствии с требованиями законодательства Российской Федерации, в том числе возможность предоставления документов и информации лицам, уполномоченным на получение таких документов и информации в соответствии с законодательством Российской Федерации.

В соответствии с частью 9 статьи 7 Федерального закона “Об организации предоставления государственных и муниципальных услуг” Правительство Российской Федерации постановляет:

1. Утвердить прилагаемые Правила межведомственного информационного взаимодействия при предоставлении государственных и муниципальных услуг, в том числе рекомендуемые правила организации межведомственного информационного взаимодействия между исполнительными органами государственной власти субъектов Российской Федерации и (или) органами местного самоуправления.

2. Рекомендовать исполнительным органам государственной власти субъектов Российской Федерации и органам местного самоуправления при предоставлении государственных и муниципальных услуг осуществлять межведомственное информационное взаимодействие в порядке, предусмотренном Правилами, утвержденными настоящим постановлением.

3. Признать утратившими силу акты Правительства Российской Федерации и отдельные положения актов Правительства Российской Федерации по перечню согласно приложению.

4. Настоящее постановление вступает в силу с 1 января 2022 г.

УТВЕРЖДЕНЫпостановлением ПравительстваРоссийской Федерацииот 23 июня 2021 г. N 963

Правиламежведомственного информационного взаимодействия при предоставлении государственных и муниципальных услуг, в том числе рекомендуемые правила организации межведомственного информационного взаимодействия между исполнительными органами государственной власти субъектов Российской Федерации и (или) органами местного самоуправления

1. Настоящие Правила определяют порядок межведомственного информационного взаимодействия при предоставлении государственных и муниципальных услуг (далее – межведомственное информационное взаимодействие), в том числе рекомендуемые правила организации межведомственного информационного взаимодействия между исполнительными органами государственной власти субъектов Российской Федерации и (или) органами местного самоуправления.

2. Межведомственное информационное взаимодействие осуществляется между органами, предоставляющими государственные услуги, органами, предоставляющими муниципальные услуги, подведомственными государственным органам или органам местного самоуправления организациями, участвующими в предоставлении государственных или муниципальных услуг, иными государственными органами, органами местного самоуправления, органами государственных внебюджетных фондов, многофункциональными центрами (далее – органы и организации) в случаях, предусмотренных законодательством Российской Федерации.

3. Межведомственное информационное взаимодействие, осуществляемое в электронной форме посредством единой системы межведомственного электронного взаимодействия (далее – межведомственное информационное взаимодействие в электронной форме), производится с учетом технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия, установленных в соответствии с постановлением Правительства Российской Федерации 8 сентября 2010 г. N 697 “О единой системе межведомственного электронного взаимодействия”, и требований, обеспечивающих технологическую совместимость информационных систем организаций, подключаемых к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме, с указанной инфраструктурой, требований к каналу связи и используемым для его защиты средствам криптографической защиты информации, а также особенностей использования стандартов и протоколов при обмене данными в электронной форме между информационными системами указанных организаций и инфраструктурой, установленных в соответствии с постановлением Правительства Российской Федерации от 22 декабря 2012 г. N 1382 “О присоединении информационных систем организаций к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме”.

4. Получение документов и (или) сведений, необходимых для предоставления государственных и муниципальных услуг (далее – сведения), инициируется посредством направления межведомственных запросов потребителем сведений и завершается получением потребителем сведений от поставщика сведений ответа на межведомственный запрос, содержащий запрашиваемые сведения и (или) информацию о причинах невозможности предоставления сведений по межведомственному запросу.

5. Межведомственное информационное взаимодействие может осуществляется на бумажном носителе:

при невозможности осуществления межведомственного информационного взаимодействия в электронной форме в связи с отсутствием запрашиваемых сведений в электронной форме;

при необходимости представления оригиналов документов на бумажном носителе при направлении межведомственного запроса.

6. Межведомственное информационное взаимодействие в электронной форме осуществляется в соответствии с форматами сведений, разработанными в соответствии с техническими требованиями к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия, утвержденными в соответствии с постановлением Правительства Российской Федерации 8 сентября 2010 г. N 697 “О единой системе межведомственного электронного взаимодействия”.

7. Органы или организации, обеспечивающие создание формата сведений, проверяют соответствие формата сведений исчерпывающему перечню документов, которые необходимы (в соответствии с нормативными правовыми актами) для предоставления государственной услуги и которые находятся в распоряжении органов и организаций, содержащемуся в административном регламенте предоставления государственной или муниципальной услуги, сформированному в федеральной государственной информационной системе “Федеральный реестр государственных и муниципальных услуг (функций)”.

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

8. Участниками межведомственного электронного взаимодействия являются органы и организации.

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

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

10. Срок предоставления сведений при межведомственном информационном взаимодействии в электронной форме не должен превышать 48 часов с момента направления межведомственного запроса.

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

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

Приложениек постановлению ПравительстваРоссийской Федерацииот 23 июня 2021 г. N 963

Переченьутративших силу актов Правительства Российской Федерации и отдельных положений актов Правительства Российской Федерации

1. Постановление Правительства Российской Федерации от 28 декабря 2011 г. N 1184 “О мерах по обеспечению перехода федеральных органов исполнительной власти и органов государственных внебюджетных фондов на межведомственное информационное взаимодействие в электронном виде” (Собрание законодательства Российской Федерации, 2012, N 1, ст. 199).

2. Пункт 8 изменений, которые вносятся в акты Правительства Российской Федерации в связи с преобразованием Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления, утвержденных постановлением Правительства Российской Федерации от 22 ноября 2013 г. N 1056 “О внесении изменений в некоторые акты Правительства Российской Федерации в связи с преобразованием Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления” (Собрание законодательства Российской Федерации, 2013, N 48, ст. 6259).

3. Постановление Правительства Российской Федерации от 26 февраля 2016 г. N 136 “О внесении изменений в постановление Правительства Российской Федерации от 28 декабря 2011 г. N 1184” (Собрание законодательства Российской Федерации, 2016, N 10, ст. 1410).

4. Пункт 20 изменений, которые вносятся в акты Правительства Российской Федерации, утвержденных постановлением Правительства Российской Федерации от 25 сентября 2018 г. N 1138 “О внесении изменений в некоторые акты Правительства Российской Федерации” (Собрание законодательства Российской Федерации, 2018, N 40, ст. 6142).

5. Пункт 6 изменений, которые вносятся в акты Правительства Российской Федерации, утвержденных постановлением Правительства Российской Федерации от 2 февраля 2019 г. N 77 “О внесении изменений в отдельные акты Правительства Российской Федерации” (Собрание законодательства Российской Федерации, 2019, N 6, ст. 533).

6. Пункт 4 изменений, которые вносятся в акты Правительства Российской Федерации, утвержденных постановлением Правительства Российской Федерации от 21 августа 2020 г. N 1266 “Об упразднении подкомиссии по цифровой экономике Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности, а также об изменении и признании утратившими силу некоторых актов Правительства Российской Федерации” (Собрание законодательства Российской Федерации, 2020, N 35, ст. 5569).

Правительство установило единый порядок межведомственного информационного взаимодействия при предоставлении государственных и муниципальных услуг. Он касается федеральных, региональных и местных органов власти, внебюджетных фондов и МФЦ.

Так, срок предоставления сведений в электронной форме не должен превышать 48 часов с момента направления межведомственного запроса. При предоставлении сведений в режиме реального времени ответ на запрос должен поступать в течение 2 секунд.

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

Постановление вступает в силу с 1 января 2022 г.

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

Рабочее взаимодействие подразумевает общение на работе только касательно самой работы. Знание правил эффективного рабочего взаимодействия поможет вам снизить вероятность недопонимания, повысить удовлетворённость коллектива, укрепить доверие и основу для совместной работы. Коллективы, умеющие эффективно взаимодействовать, лучше справляются с возникающими трудностями. Но формирование конструктивного взаимодействия требует времени и сил — вот тут-то мы и приходим на помощь с нашими 12 способами вывести навыки рабочего взаимодействия на новый уровень.

Что подразумевается под рабочим взаимодействием?

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

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

• Обмен информацией о статусе проекта или ходе работ
• Совместная работа над задачами со специалистами из разных подразделений
• Невербальный обмен информацией

Повысить эффективность командной работы с помощью Asana

Элементы эффективного взаимодействия

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

• Подразумевает чёткость. Отправляя сообщение в Slack, составляя письмо по электронной почте или отвечая на чей-то запрос, старайтесь чётко доносить то, что хотите сказать.
• Является двухсторонним. Любое рабочее взаимодействие представляет собой обмен информацией, даже если она передаётся невербальным способом и только одним человеком.

Преимущества открытого рабочего взаимодействия

Чёткое эффективное рабочее взаимодействие позволяет:

• Повышать вовлечённость и причастность сотрудников
• Стимулировать интерес коллектива
• Формировать здоровую рабочую атмосферу и организационную культуру
• Нивелировать конфликтные ситуации

Читать о том, что такое матричная организация и как она работает