Интегрирование в бизнесе это

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

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

ИНТЕГРАЛ С НУЛЯ | определенный интеграл | ТАБЛИЦА ИНТЕГРАЛОВ | сумма Римана

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

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

Зачем нужен ИНТЕГРАЛ. Объяснение математического смысла.

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

— Таким образом, интегральный подход, прежде всего, является способом оценки и принятия решения?
Да. Я бы сказал, наиболее всесторонним способом решения сложных, комплексных проблем и достижения амбициозных задач. Когда Вы сталкиваетесь с комплексными задачами, с помощью интегрального подхода Вы получаете возможность решить их наилучшим образом.
Это описание типа мышления, понимания, осознания. Простое формальное применение интегрального подхода к комплексной ситуации недостаточно, бесполезно. Необходимо внутреннее соответствие, осознание, без которого простое применение карты не будет успешным само по себе.

Если руководитель считает достаточным лишь формальное применение Интегральной карты, это нельзя назвать интегральным подходом. Это неэффективный метод. Руководитель должен иметь способность применять интегральную карту по отношению к себе самому. Иначе ничего не получится.
В Америке многие используют терминологию интегрального подхода. Но это лишь бессмысленное копирование. Знаете, есть такая поговорка: «Не зная брода, не суйся в воду».

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

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

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

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

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

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

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

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

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

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

— В чем заключается популярность, насущность и актуальность интегрального подхода?
Мой опыт работы в США показывает, что отдельные аспекты интегрального подхода очень популярны, поскольку они неизменны и легки для понимания. Инженеры, например, или ученые, обычно фокусируют свое внимание на достижении результата. Квадраты карты помогают им со всех сторон взглянуть на действительность.

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

Для решения комплексных проблем необходимо системное мышление. Когда я приступил к консалтинговой практике в 1984 году, большинство проблем, стоящих перед руководителями, было новыми для них проблемами, но они догадывались, где искать ответы на свои вопросы.

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

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

Карта – это вспомогательное средство. Интегральный подход – это отношение, это способ бытия. Можно даже сказать — предрасположенность. Это, скорее, не состояние знания, а процесс познавания. Его сущность в исследовании, вопрошании.

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

— Что необходимо для его применения?
Надо сказать, что не всякая проблема нуждается в интегральном подходе. Иногда, когда Вы сталкиваетесь с какой-то проблемой, Вы можете просто взять и решить ее. Однако, когда Вы находитесь в ситуации, когда Вы обладаете достаточным кругозором, достаточно полным видением или сложность, с которой Вы сталкиваетесь, достаточно велика, интегральный подход, на мой взгляд, является вашим конкурентным преимуществом.
Еще один важный компонент – необходимо иметь желание сбавить скорость, чтобы, осознав и осмыслив ситуацию, вынеся из нее уроки, затем ускориться. Это образ мыслей успешного человека.
Руководителю следует думать не в краткосрочных масштабах, ему следует думать о своей деятельности, как о некоем наследии; о том, какое наследие он хочет оставить после себя.
И не нужно бояться тяжелых разговоров — и с самим собой — когда замечаешь, что в чем-то неэффективен, когда видишь какие -то неприятные стороны себя; и с другими людьми, когда приходится слышать что-то, что не нравится . И во внутреннем и во внешнем конфликте гораздо больше потенциала, чем угроз , надо лишь уметь его извлечь.
И еще. Руководителю так же следует понимать, что собственное развитие и развитие подчиненных критически важны для будущего успеха. Это не то, чем надо заниматься, когда дело уже сделано. Это часть самого дела. Это новый способ сделать дело.

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

— Что-то еще, что мы не спросили, но вы считаете важным об этом сказать?
Я хотел бы сказать еще кое-что в качестве побуждения. Следует больше стремиться к прекрасному, нежели к правильному. Любой может научиться интегральному подходу с его картами и моделями. Но для того, чтобы прочувствовать его, сделать его своим центром и центром своего бизнеса, необходимо обладать смирением, скромностью, простотой.

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

• Двухступенчатая программа переподготовки«Интегральные технологии развития людей и организаций», Санкт-Петербург
• Дистанционный курс«Недирективный стиль управления: переход от Я к Мы»

Источник: coachinstitute.ru

Интеграции бояться — в аналитики не идти

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

Совсем недавно рассказывала об этом на AnalystDays’13. Интерес аудитории к моему докладу сподвиг обобщить мои мысли в виде статьи.

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

Что такое интеграционное взаимодействие?

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

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

Почему это сложно?

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

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

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

Как не наступить на грабли?

Готового шаблона быть не может. От задачи к задаче процесс изменяется. Но можно дать общие рекомендации. Для этого пройдемся по основным этапам разработки интеграционного взаимодействия.

Разработка технического задания

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

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

Однажды на проекте в сфере здравоохранения я столкнулась с такой ситуацией.

Кейс 1. А отменить?

Одной из первых моих интеграционных задач был обмен такими сущностями, как направление на оказание медицинской помощи. Мы интегрировались через шину данных, обмениваясь данными по SOAP протоколу. Наша система была источником данных, а получателем была медицинская ИС, разработанная внешним вендором. У нас на руках был согласованный государственным заказчиком пакет документов – ТЗ, ПМИ (программа и методика испытаний). И уже на приемке под конец бизнес-тестирования, когда заветные акты о выполненных работах были близки к подписанию, вдруг возникает вопрос заказчика: ”А давайте попробуем отменить направление?”.

И тут все, мягко говоря, позеленели. Казалось бы, такой необходимый процесс – отмена направления. Но в ТЗ было сказано «Обмен направлениями» без детализации. И об отмене напрочь забыли. Естественно, приемка закончилась не так, как ожидалось.

В целом моделирование данных и проверка функционала по добавлению/чтению/изменению/удалению (или CRUD) — отличный способ избежать подобных ситуаций!

На что обратить внимание

Чтобы не столкнуться с подобными ситуациями, уже на этапе написания ТЗ необходимо учесть следующие моменты:

• Цель. Вы должны четко понимать, в чем основная цель интеграции – какую задачу предстоит решить в конечном итоге. В приведенном кейсе мы неправильно поняли основную цель. Обмен предусмотрели только в одну сторону.
• Описание бизнес-процесса. Необходимо максимально детально расписать все возможные сценарии интеграционного бизнес-процесса. На мой взгляд, лучше потратить на это больше времени и избежать любых разночтений в требованиях, чем краснеть на приемке за свое упущение.
• Способ интеграционного взаимодействия. Способов немало, они все широко известны и описаны в профессиональной литературе и интернете. Здесь я не буду их перечислять. Скажу только, что от выбранного способа напрямую зависит тот перечень обязательной информации, без которой поставленную задачу не решить. От себя порекомендую хорошую книжку — Шаблоны интеграции корпоративных приложений Грегора Хопа и Бобби Вулфа. Из нее можно узнать, какие есть паттерны. Книжка ориентирована на архитекторов, но будет полезна не только им и разработке, но и аналитикам.
• Данные, которыми необходимо обмениваться. При проектировании ТЗ нужно четко понимать, что вы передаете, что принимаете, что из этого будет обязательным по спецификации и в каком формате данные будут переданы. Если пропустить обязательный тег или послать пустое значение вместо ожидаемого непустого, успешного взаимодействия реализовать не получится. Придется тратить ресурсы на доработку.
• Проектная документация внешней системы. При проектировании взаимодействия необходимо досконально изучить документацию интегрируемой системы. Иногда уже на сдаче проекта выясняется, что неучтенная фраза в документации означает целый бизнес-процесс, который в итоге окажется нереализованным. Понимание внешней системы упростит задачу.

Кстати, на этом этапе также рекомендую подумать о плане тестирования — тест-кейсах. Это поможет при приемке.

Проектирование взаимодействия

В качестве следующей иллюстрации к моему рассказу вспоминается еще один пример.

Кейс 2. Когда архитектора нет

На одном из моих прошлых проектов переходили от монолита к микросервисам. Задача была непростая, а архитектора у нас не было. Его функции закрывали product owner, тимлид команды и я, как аналитик.

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

Данные лежали в реляционной БД. Мы начали с доработки схемы хранения. Далее продумывали, как сервисы будут взаимодействовать. На тот момент мы выбрали распределенные очереди сообщений, но не буду вдаваться в технические подробности.

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

Проект был условно поделен на 3 этапа по полгода каждый. Сначала внедрили реструктурированную БД, далее частично взаимодействие между сервисами. В конце полностью перенесли основной бизнес-функционал на микросервисную архитектуру. Таким образом проект успешно был реализован, а сам переход от монолита к микросервису занял примерно 1,5 года.

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

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

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

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

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

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

Разработка

И вот у вас на руках готовое ТЗ, выбран паттерн, пришло время реализации.

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

Тут напрашивается еще один пример…

Кейс 3. Трудности перевода

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

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

Вот такие бывают трудности перевода.

Роль аналитика на этапе разработки

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

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

Тестирование

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

Кейс 4. А ты подготовил тесты?

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

Разработка заняла несколько дней, однако тестирование затянулось почти на месяц! Все потому, что мы заранее не согласовали сценарии тестирования, а заказчик решил проверить функционал на принципиально разных контрагентах. Не буду вдаваться в банковские подробности, скажу только, что от типа контрагента (физическое или юридическое лицо, резидент или не резидент РФ) немного меняется функционал. Отсутствие заранее согласованных тестов, увы, стоило нам сдвинутых сроков, и слегка потрепанных нервов.

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

На что обратить внимание

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

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

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

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

Если же говорить об успешных кейсах, то тут мне есть чем гордится. Я работала над проектированием интеграционной шины данных для региональных проектов здравоохранения, чтобы обеспечивать работу Единой Государственной Системы в сфере здравоохранения (ЕГИСЗ).

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

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

Автор статьи: Лейла Кадырова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

• системный анализ
• интеграция
• интеграция сервисов
• интеграция систем

• Блог компании Maxilect
• Анализ и проектирование систем
• Аналитика мобильных приложений
• Карьера в IT-индустрии

Источник: habr.com