BA & SA митап online
Сегодня в 19.00 (GMT+3)
Интереснейший митап для системных и бизнес аналитиков, который можно посмотреть онлайн!
Эксперты из Andersen, Альфа-Банк и Deutsche Bank TechCentre расскажут вам о развитии проектов, о работе банковских SA и использовании интеграций в FinTech домене.
🗣 Спикеры:
👉🏻 Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
👉🏻 Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
👉🏻 Андрей Абразовский - Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.
Подключайтесь: https://www.youtube.com/watch?v=7k4SPbOdAGM
Ставьте лайки, жмите колокольчик!
Сегодня в 19.00 (GMT+3)
Интереснейший митап для системных и бизнес аналитиков, который можно посмотреть онлайн!
Эксперты из Andersen, Альфа-Банк и Deutsche Bank TechCentre расскажут вам о развитии проектов, о работе банковских SA и использовании интеграций в FinTech домене.
🗣 Спикеры:
👉🏻 Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
👉🏻 Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
👉🏻 Андрей Абразовский - Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.
Подключайтесь: https://www.youtube.com/watch?v=7k4SPbOdAGM
Ставьте лайки, жмите колокольчик!
YouTube
SA/BA meetup (rus)
As part of the IT Community, we hold free meetups featuring top speakers from Andersen and invited experts for IT specialists across various technologies.
At this meetup experts from Andersen, Alfa-Bank and Deutsche Bank Tech Centre talked about the development…
At this meetup experts from Andersen, Alfa-Bank and Deutsche Bank Tech Centre talked about the development…
Как провести хороший онбординг новому сотруднику.
Важные артефакты онбординга.
🤝 Силу хорошего онбординга очень легко оценить, как и его отсутствие. Многие недооценивают эту фазу в жизни начинающего сотрудника в компании или проекте или и проводят ради соблюдения формальностей. Реальность же говорит о том, что в коллективе с плохим онбордингом есть люди, которые могут не до конца понимать, что за продукт они делают, или чувствовать себя одиноко из-за того, что не подружились ни с кем на новом месте.
👉🏻 Разберем по пунктам из чего должен состоять ваш идеальный онбординг:
1️⃣ До прихода сотрудника распишите план онбординга.
📌 Определите инструмент в котором план онбординга всегда будет доступен для новых сотрудников.
📌 Добавьте в план онбординга вводные ("read me" пояснения, как применять).
📌 Составьте полный список полезных ссылок и ссылок на сервисы/инструменты к которым сотруднику дадут доступ.
📌 Разделите ваш план онбординга на этапы с определенной длительностью: например первая неделя, 30 дней, 60 дней, 90 дней.
📌 Каждый этап должен включать в себя 1:1 встречи с ответственным в начале этапа .
📌 Каждый этап может включать набор задач для сотрудника и даже ответственных, кто поможет достичь успеха: например назначить того, кто устроит презентацию продукта.
📌 Добавьте к каждому этапу чеклист, чтобы сотрудник мог отметить, что выполнил этап, например понял ценности компании.
📌 Добавьте этап, с заданием найти себе товарища в коллективе.
📌 На каждый этап по необходимости давайте подсказки, полезные ссылки, ответственных людей, чтобы достичь успеха.
2️⃣ Поделитесь планом онбординга с новым сотрудником.
3️⃣ Следите за тем, как сотрудник продвигается по плану.
4️⃣ Если выполнение онбординга нуждается во встречах с членами коллектива, то забронируйте эти встречи в календаре у них.
🎉 Всем желаем качественных онбордингов.
Важные артефакты онбординга.
🤝 Силу хорошего онбординга очень легко оценить, как и его отсутствие. Многие недооценивают эту фазу в жизни начинающего сотрудника в компании или проекте или и проводят ради соблюдения формальностей. Реальность же говорит о том, что в коллективе с плохим онбордингом есть люди, которые могут не до конца понимать, что за продукт они делают, или чувствовать себя одиноко из-за того, что не подружились ни с кем на новом месте.
👉🏻 Разберем по пунктам из чего должен состоять ваш идеальный онбординг:
1️⃣ До прихода сотрудника распишите план онбординга.
📌 Определите инструмент в котором план онбординга всегда будет доступен для новых сотрудников.
📌 Добавьте в план онбординга вводные ("read me" пояснения, как применять).
📌 Составьте полный список полезных ссылок и ссылок на сервисы/инструменты к которым сотруднику дадут доступ.
📌 Разделите ваш план онбординга на этапы с определенной длительностью: например первая неделя, 30 дней, 60 дней, 90 дней.
📌 Каждый этап должен включать в себя 1:1 встречи с ответственным в начале этапа .
📌 Каждый этап может включать набор задач для сотрудника и даже ответственных, кто поможет достичь успеха: например назначить того, кто устроит презентацию продукта.
📌 Добавьте к каждому этапу чеклист, чтобы сотрудник мог отметить, что выполнил этап, например понял ценности компании.
📌 Добавьте этап, с заданием найти себе товарища в коллективе.
📌 На каждый этап по необходимости давайте подсказки, полезные ссылки, ответственных людей, чтобы достичь успеха.
2️⃣ Поделитесь планом онбординга с новым сотрудником.
3️⃣ Следите за тем, как сотрудник продвигается по плану.
4️⃣ Если выполнение онбординга нуждается во встречах с членами коллектива, то забронируйте эти встречи в календаре у них.
🎉 Всем желаем качественных онбордингов.
Митап идёт прямо сейчас, подключайтесь.
Мы переходим к следующему докладу на нашем митапе. Следующие спикеры:
👉🏻 Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
👉🏻 Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
Подключайтесь: https://www.youtube.com/watch?v=7k4SPbOdAGM
Мы переходим к следующему докладу на нашем митапе. Следующие спикеры:
👉🏻 Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
👉🏻 Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
Подключайтесь: https://www.youtube.com/watch?v=7k4SPbOdAGM
YouTube
SA/BA meetup (rus)
As part of the IT Community, we hold free meetups featuring top speakers from Andersen and invited experts for IT specialists across various technologies.
At this meetup experts from Andersen, Alfa-Bank and Deutsche Bank Tech Centre talked about the development…
At this meetup experts from Andersen, Alfa-Bank and Deutsche Bank Tech Centre talked about the development…
Как и обещали, выкладываем презентации наших крутых спикеров с прошедшего митапа в формате PDF📃. А также, если кто то пропустил митап, дублируем ссылку на просмотр:
https://www.youtube.com/watch?v=7k4SPbOdAGM
1️⃣ Андрей Абразовский - Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.
Видео: минуты с 11.40 до 48.20
2️⃣ Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
Видео: минуты с 48.30 до 1.25.00
3️⃣ Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
Видео: минуты с 1.25.20 до 2.00.20
https://www.youtube.com/watch?v=7k4SPbOdAGM
1️⃣ Андрей Абразовский - Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.
Видео: минуты с 11.40 до 48.20
2️⃣ Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
Видео: минуты с 48.30 до 1.25.00
3️⃣ Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
Видео: минуты с 1.25.20 до 2.00.20
YouTube
SA/BA meetup (rus)
As part of the IT Community, we hold free meetups featuring top speakers from Andersen and invited experts for IT specialists across various technologies.
At this meetup experts from Andersen, Alfa-Bank and Deutsche Bank Tech Centre talked about the development…
At this meetup experts from Andersen, Alfa-Bank and Deutsche Bank Tech Centre talked about the development…
Сегодня удивительный день в истории ИТ: День Рождения интернета🎉🎉🎉
🎈 29 октября 1969 года аспирант Калифорнийского университета в Лос-Анджелесе (UCLA) передал текст, состоящий из букв L-O, на удалённый компьютер двоих представителей Стэндфордского университета.
🎈 Двумя представителями Стэндфордского университета были Билл Дювалл и Чарли Клайн, а передаваемые буквы были началом слова «login», однако, компьютер принимающей стороны «завис», не дав закончить передачу всего слова. Позже их компьютеры были соединены с компьютерами в Университете штата Юта и Калифорнийском университете в Санта-Барбара, благодаря чему была создана сеть ARPANET (Сеть агентства передовых исследовательских проектов).
💻 Многие технические решения, порождённые этим прототипом, используются в глобальной сети по сей день.
💻 Так, многие существующие протоколы Интернета берут начало именно в ARPANET. Например, протокол обратного поиска DNS до сих пор использует доменное имя верхнего уровня «arpa»: чтобы найти записи, относящиеся к IP-адресу 1.2.3.4, надо послать запрос об адресе 4.3.2.1.in-addr.arpa. Основной протокол передачи данных сети Интернет — TCP/IP, тоже берёт начало в ARPANET.
🎈🎈🎈Так что, с Днем Рождения интернета!🎉🎉🎉
🎈 29 октября 1969 года аспирант Калифорнийского университета в Лос-Анджелесе (UCLA) передал текст, состоящий из букв L-O, на удалённый компьютер двоих представителей Стэндфордского университета.
🎈 Двумя представителями Стэндфордского университета были Билл Дювалл и Чарли Клайн, а передаваемые буквы были началом слова «login», однако, компьютер принимающей стороны «завис», не дав закончить передачу всего слова. Позже их компьютеры были соединены с компьютерами в Университете штата Юта и Калифорнийском университете в Санта-Барбара, благодаря чему была создана сеть ARPANET (Сеть агентства передовых исследовательских проектов).
💻 Многие технические решения, порождённые этим прототипом, используются в глобальной сети по сей день.
💻 Так, многие существующие протоколы Интернета берут начало именно в ARPANET. Например, протокол обратного поиска DNS до сих пор использует доменное имя верхнего уровня «arpa»: чтобы найти записи, относящиеся к IP-адресу 1.2.3.4, надо послать запрос об адресе 4.3.2.1.in-addr.arpa. Основной протокол передачи данных сети Интернет — TCP/IP, тоже берёт начало в ARPANET.
🎈🎈🎈Так что, с Днем Рождения интернета!🎉🎉🎉
Врываемся в ноябрь с Global Business Analyst Day!🎉
Всех бизнес-аналитиков с профессиональным праздником!💻🎈
Всех бизнес-аналитиков с профессиональным праздником!💻🎈
📃 Области рисков в бизнес анализе
Говоря про риски, хочется начать с определения термина, предложенного многоуважаемым Карлом Вигерсом. Итак, «риск — это условие, которое может повлечь какие — либо потери или другим способом поставить под угрозу успех проекта. Это условие ещё не породило проблему, и нужно, чтобы оно так и оставалось. 👉🏻 Эти потенциальные проблемы могут оказать неблагоприятное воздействие на стоимость, сроки, технический успех, качество продукта или эффективность работы команды».
Иными словами, риск — это неопределённое условие или событие, которое при наступлении может иметь негативный или позитивный эффект по отношению к бизнес — анализу.
Нас, в первую очередь, естественно, волнует негативный эффект, который могут принести риски. Давайте рассмотрим области рисков в бизнес — анализе.
1️⃣ Решения вместо потребностей
Вероятность того, что заинтересованные лица будут навязывать решения вместо потребностей, что повлечёт за собой разработку ненужного функционала, либо попросту трату времени на прояснение этих самых потребностей.
2️⃣ Scope creep
Неконтролируемое расширение границ решения в силу забывчивости, «передумывания» заказчика, что влечёт за собой увеличение параметров проекта, которое не на руку компании исполнителя.
3️⃣ Ограниченные искусственно сроки на разработку требований
На этапе переговоров, предложили максимально сжатые сроки, дабы проект «выгорел». Как итог - получили риск.
4️⃣ Несогласие со стороны клиента.
Неверно понятые требования — следствие ошибки аналитика.
5️⃣ Неявные, скрытые требования.
Когда есть что — то само собой разумеющееся, а потому не озвучивается и, как следствие, не учитывается аналитиком.
6️⃣ Неверная приоритизация.
Неверная приоритезация может повлечь недовольство со стороны клиента.
7️⃣ Непровалидированные, непроверифицированные требования.
🖍 Непровалидированные требования — требования, которые потенциально не отражают потребностей заинтересованных лиц, а значит потенциально направлены на разработку ненужного функционала.
🖍 Непроверифицированные требования — потенциально некачественные требования: неполные, некорректные и т. д. Отсутствие одного из качеств хорошо написанных требований может привести к ряду проблем.
👉🏻 Само собой, перечисленный в статье список не является избыточным. Риски могут крыться и в других областях, но главное для аналитика - вовремя их идентифицировать и вести работу с ними непрерывно.
Говоря про риски, хочется начать с определения термина, предложенного многоуважаемым Карлом Вигерсом. Итак, «риск — это условие, которое может повлечь какие — либо потери или другим способом поставить под угрозу успех проекта. Это условие ещё не породило проблему, и нужно, чтобы оно так и оставалось. 👉🏻 Эти потенциальные проблемы могут оказать неблагоприятное воздействие на стоимость, сроки, технический успех, качество продукта или эффективность работы команды».
Иными словами, риск — это неопределённое условие или событие, которое при наступлении может иметь негативный или позитивный эффект по отношению к бизнес — анализу.
Нас, в первую очередь, естественно, волнует негативный эффект, который могут принести риски. Давайте рассмотрим области рисков в бизнес — анализе.
1️⃣ Решения вместо потребностей
Вероятность того, что заинтересованные лица будут навязывать решения вместо потребностей, что повлечёт за собой разработку ненужного функционала, либо попросту трату времени на прояснение этих самых потребностей.
2️⃣ Scope creep
Неконтролируемое расширение границ решения в силу забывчивости, «передумывания» заказчика, что влечёт за собой увеличение параметров проекта, которое не на руку компании исполнителя.
3️⃣ Ограниченные искусственно сроки на разработку требований
На этапе переговоров, предложили максимально сжатые сроки, дабы проект «выгорел». Как итог - получили риск.
4️⃣ Несогласие со стороны клиента.
Неверно понятые требования — следствие ошибки аналитика.
5️⃣ Неявные, скрытые требования.
Когда есть что — то само собой разумеющееся, а потому не озвучивается и, как следствие, не учитывается аналитиком.
6️⃣ Неверная приоритизация.
Неверная приоритезация может повлечь недовольство со стороны клиента.
7️⃣ Непровалидированные, непроверифицированные требования.
🖍 Непровалидированные требования — требования, которые потенциально не отражают потребностей заинтересованных лиц, а значит потенциально направлены на разработку ненужного функционала.
🖍 Непроверифицированные требования — потенциально некачественные требования: неполные, некорректные и т. д. Отсутствие одного из качеств хорошо написанных требований может привести к ряду проблем.
👉🏻 Само собой, перечисленный в статье список не является избыточным. Риски могут крыться и в других областях, но главное для аналитика - вовремя их идентифицировать и вести работу с ними непрерывно.
Транзитные требования. Что это и как писать👇🏻
📍 Существуют случаи, когда предприятия внедряют новые ИТ решения как замену существующим. В тот промежуток времени, когда работают старое и новое решение, организации может потребоваться перемещать информацию между новой и старой системой, проводить обучение новому ПО для заинтересованных сторон и так далее.
Помимо разработки новой системы, разработчикам скорее всего придется имплементировать дополнительные решения, которые бы позволили осуществить и сам переход.
📍 Таким образом, транзитивные требования – это требования, которое должны выполняться в течение перехода организации от старой системы к новой. Срок действия этих требований - время переходного периода между решениями.
📍 В случае, если организация-заказчик планирует внедрить у себя новый ИТ продукт, который предоставляет совершенно новые возможности, а не является улучшением существующей системы, то транзитивные требования не анализируются, поскольку они и не существуют.
📌 В ходе написания транзитивных требований необходимо:
1️⃣ Исследовать существующую систему чтобы понять, что нужно перевести на новое решение.
2️⃣ Определить готовность организации к внедрению новой системы. Может будет необходимо добавить новые возможности в организации в определенных сферах чтобы эксплуатация нового решения стала возможна.
3️⃣ Обозначить информацию и процессы, которые будут необходимы для заинтересованных сторон во время перехода.
4️⃣ Проработать дизайн (в том числе архитектурный), чтобы можно было выявить основные различия между двумя системами.
5️⃣ Оценить текущие данные, чтобы определить, следует ли архивировать их или передать в новое решение. Кроме того, потребуется разработать правила преобразования этой информации и, возможно, определить бизнес-правила.
6️⃣ Предусмотреть варианты управления текущей работой. Возможны варианты: завершение текущих задач в старой системе и инициация всех новых работ в новой системе, приостановка текущих задач до ввода новой системы, преобразование всей работы в период имплементации новой системы и др.
7️⃣ Может потребоваться разработать рекомендации по изменению организационной структуры предприятия или функций персонала, поскольку должностные обязанности могут значительно измениться в результате автоматизации работы.
📌 Полезные инструменты, используемые при сборе транзитивных требований:
👉🏻 Анализ бизнес-правил: могут быть определены дополнительные бизнес-правила для переноса данных или для управления работой, перенесенной из существующего решения.
👉🏻 Диаграммы потоков данных, моделирование процессов и организационное моделирование.
👉🏻 Моделирование данных для оценки их сопоставимости в старом и новом решениях.
📍 Существуют случаи, когда предприятия внедряют новые ИТ решения как замену существующим. В тот промежуток времени, когда работают старое и новое решение, организации может потребоваться перемещать информацию между новой и старой системой, проводить обучение новому ПО для заинтересованных сторон и так далее.
Помимо разработки новой системы, разработчикам скорее всего придется имплементировать дополнительные решения, которые бы позволили осуществить и сам переход.
📍 Таким образом, транзитивные требования – это требования, которое должны выполняться в течение перехода организации от старой системы к новой. Срок действия этих требований - время переходного периода между решениями.
📍 В случае, если организация-заказчик планирует внедрить у себя новый ИТ продукт, который предоставляет совершенно новые возможности, а не является улучшением существующей системы, то транзитивные требования не анализируются, поскольку они и не существуют.
📌 В ходе написания транзитивных требований необходимо:
1️⃣ Исследовать существующую систему чтобы понять, что нужно перевести на новое решение.
2️⃣ Определить готовность организации к внедрению новой системы. Может будет необходимо добавить новые возможности в организации в определенных сферах чтобы эксплуатация нового решения стала возможна.
3️⃣ Обозначить информацию и процессы, которые будут необходимы для заинтересованных сторон во время перехода.
4️⃣ Проработать дизайн (в том числе архитектурный), чтобы можно было выявить основные различия между двумя системами.
5️⃣ Оценить текущие данные, чтобы определить, следует ли архивировать их или передать в новое решение. Кроме того, потребуется разработать правила преобразования этой информации и, возможно, определить бизнес-правила.
6️⃣ Предусмотреть варианты управления текущей работой. Возможны варианты: завершение текущих задач в старой системе и инициация всех новых работ в новой системе, приостановка текущих задач до ввода новой системы, преобразование всей работы в период имплементации новой системы и др.
7️⃣ Может потребоваться разработать рекомендации по изменению организационной структуры предприятия или функций персонала, поскольку должностные обязанности могут значительно измениться в результате автоматизации работы.
📌 Полезные инструменты, используемые при сборе транзитивных требований:
👉🏻 Анализ бизнес-правил: могут быть определены дополнительные бизнес-правила для переноса данных или для управления работой, перенесенной из существующего решения.
👉🏻 Диаграммы потоков данных, моделирование процессов и организационное моделирование.
👉🏻 Моделирование данных для оценки их сопоставимости в старом и новом решениях.
❗️ Вы системный аналитик? Тогда для вас новости!
👉🏻 IT компания Andersen запускает программу "SA hiring days! Получи Job Offer в 3 шага!"
👉🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
👉🏻 IT компания Andersen запускает программу "SA hiring days! Получи Job Offer в 3 шага!"
👉🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
Друзья, всем привет!👋
Для тех, кто давно хотел начать карьеру в системной аналитике, стартует набор на бесплатный online-курс "System Analysis"😊.
Начало уже в декабре. Два месяца, два раза в неделю(три часа) вечером.
Вся информация в "шапке" регистрационной формы⬇️ https://forms.gle/fo4BrW9yvQVtp3T46
Для тех, кто давно хотел начать карьеру в системной аналитике, стартует набор на бесплатный online-курс "System Analysis"😊.
Начало уже в декабре. Два месяца, два раза в неделю(три часа) вечером.
Вся информация в "шапке" регистрационной формы⬇️ https://forms.gle/fo4BrW9yvQVtp3T46
Что такое Customer Journey Map и чем она полезна аналитику
👉 Карта путешествия клиента - Customer journey map (CJM) – это описание шагов, которые проходят пользователи при взаимодействии с компанией/продуктом, будь то онлайн-опыт, опыт розничной торговли, получение услуги или любая их комбинация.
Все пункты карты путешествия клиента принято называть точками контакта, они могут быть как онлайн так и оффлайн точками. Примеры онлайн точек: сайт, чат-бот, отзывы в Интернет, статьи, социальная сеть, онлайн-пощник, смс, мобильное приложение и др. Оффлайн точки контакта: консультант в магазине, каталог продукции, доставщик товара, сам товар, бизнес-процесс, реклама в печатных СМИ и др.
👉 В общем виде CJM – это таблица, иногда с элементами графического изображения. Не существуют унифицированного шаблона для CJM, однако можно выделить несколько основных элементов CJM:
1️⃣ Вертикальные столбцы. Имеют название этапов, проходимых клиентом. Например, если речь идет о покупке товара в интернет-магазине, то столбцы имели бы название желание приобрести, поиск, выбор, покупка, доставка, использование, лояльность.
2️⃣ Горизонтальные строки. Отражают характеристики для каждого этапа, т.е. как, когда, где и при каких условиях происходит взаимодействие. Например, для той же покупки в интернет-магазине, это были бы следующие строки: действия покупателя, цели покупателя, точки контакта, полученный опыт (эмоциональная оценка), проблемы, их решения, вовлеченные технические средства и т.д.
❗Особенности написания CJM:
📌 Количество как горизонтальных, так и вертикальных строк можно увеличивать или сокращать в зависимости от потребностей при описании CJM;
📌 Карта может разрабатываться для каждой пользовательской персоны, для персоны приносящей больше прибыли или для наиболее типичной персоны;
📌 Карта пригодна не только для более масштабного описания взаимодействия с продуктом выходящего за рамки посещения сайта (как в случае покупки товара онлайн), так и для описания более точечного взаимодействия (CJM покупки товара на самом сайте).
👉 CJM помогает:
📍систематизировать понимание о взаимодействии клиента с продуктом по разным каналам;
📍спрогнозировать поведение клиента в будущем;
📍при создании положительного UX (user experience) на всем протяжении использования продукта/услуги. Это непосредственно влияет на лояльность клиентов, т.е. приверженность к продукту и готовность вернуться к нему в будущем;
📍выявить и устранить барьеры при переходе от одной точки контакта к другой, тем самым доводя больше потребителей до цели.
👉 Карта путешествия клиента - Customer journey map (CJM) – это описание шагов, которые проходят пользователи при взаимодействии с компанией/продуктом, будь то онлайн-опыт, опыт розничной торговли, получение услуги или любая их комбинация.
Все пункты карты путешествия клиента принято называть точками контакта, они могут быть как онлайн так и оффлайн точками. Примеры онлайн точек: сайт, чат-бот, отзывы в Интернет, статьи, социальная сеть, онлайн-пощник, смс, мобильное приложение и др. Оффлайн точки контакта: консультант в магазине, каталог продукции, доставщик товара, сам товар, бизнес-процесс, реклама в печатных СМИ и др.
👉 В общем виде CJM – это таблица, иногда с элементами графического изображения. Не существуют унифицированного шаблона для CJM, однако можно выделить несколько основных элементов CJM:
1️⃣ Вертикальные столбцы. Имеют название этапов, проходимых клиентом. Например, если речь идет о покупке товара в интернет-магазине, то столбцы имели бы название желание приобрести, поиск, выбор, покупка, доставка, использование, лояльность.
2️⃣ Горизонтальные строки. Отражают характеристики для каждого этапа, т.е. как, когда, где и при каких условиях происходит взаимодействие. Например, для той же покупки в интернет-магазине, это были бы следующие строки: действия покупателя, цели покупателя, точки контакта, полученный опыт (эмоциональная оценка), проблемы, их решения, вовлеченные технические средства и т.д.
❗Особенности написания CJM:
📌 Количество как горизонтальных, так и вертикальных строк можно увеличивать или сокращать в зависимости от потребностей при описании CJM;
📌 Карта может разрабатываться для каждой пользовательской персоны, для персоны приносящей больше прибыли или для наиболее типичной персоны;
📌 Карта пригодна не только для более масштабного описания взаимодействия с продуктом выходящего за рамки посещения сайта (как в случае покупки товара онлайн), так и для описания более точечного взаимодействия (CJM покупки товара на самом сайте).
👉 CJM помогает:
📍систематизировать понимание о взаимодействии клиента с продуктом по разным каналам;
📍спрогнозировать поведение клиента в будущем;
📍при создании положительного UX (user experience) на всем протяжении использования продукта/услуги. Это непосредственно влияет на лояльность клиентов, т.е. приверженность к продукту и готовность вернуться к нему в будущем;
📍выявить и устранить барьеры при переходе от одной точки контакта к другой, тем самым доводя больше потребителей до цели.
Приятная новость😉 Ведущий BA из Andersen - Виталий Бирченко - выступит на ANALYST DAYS!
Тринадцатая Международная Конференция, посвященная системному и бизнес анализу, пройдет в Москве 19-20 ноября. Спикер из Andersen поделится своим опытом и выступит 19 ноября с докладом: “BA vs SME. Взаимодействие вместо противостояния”. Разбор темы на реальных Healthcare кейсах будет интересен как аналитикам, так и экспертам.
Желаем Виталию классно выступить💪
👉 Познакомиться со всей программой ANALYST DAY/13 и купить на него билеты можно по ссылке👇
https://analystdays.ru/ru/index
Тринадцатая Международная Конференция, посвященная системному и бизнес анализу, пройдет в Москве 19-20 ноября. Спикер из Andersen поделится своим опытом и выступит 19 ноября с докладом: “BA vs SME. Взаимодействие вместо противостояния”. Разбор темы на реальных Healthcare кейсах будет интересен как аналитикам, так и экспертам.
Желаем Виталию классно выступить💪
👉 Познакомиться со всей программой ANALYST DAY/13 и купить на него билеты можно по ссылке👇
https://analystdays.ru/ru/index
Всем замечательного понедельника! 🔆
Сегодня поговорим о системном анализе, а именно об объектах и методах интеграции.☝🏻💻
➡️ Объект интеграции - компонент интегрируемых информационных систем. Объектами интеграции могут выступать:
📍 платформы (ОС Windows, ОС Linux, сервер Intel Xeon и т.п.);
📍 данные (БД, СУБД Oracle Database, Microsoft SQL Server и т.п.);
📍 приложения (сервер приложений Microsoft, Java Runtine Environment, бизнес-логика или интерфейс какого-то приложения и т.п.);
📍 бизнес-процессы (функции сотрудников).
👉🏻 Интеграция платформ - это установление взаимодействия между приложениями, работающими на различных платформах (например, между приложениями на Linux и Windows), а также обеспечение работы приложений, разработанных для одной платформы, на других платформах (например, приложений Windows на платформе Solaris).
➡️ Интеграция платформ осуществляется следующими методами:
📍 Удаленный вызов процедур (remote procedure call RPC, Web-сервисы, REST и др.);
📍 ПО промежуточного слоя (Microsoft.Net, Java Runtime);
📍 Виртуализация - технология программного представления виртуальной версии ИТ-продуктов.
Интеграция данных предполагает совместное использование данных различных систем.
Осуществляется следующими методами:
📍 Универсальный доступ к данным - например, есть две БД, мы интегрируем одну со второй так, что первая получает всю необходимую информацию со второй по средствам запросов на выборку данных;
📍 Хранилища данных – информация с нескольких информационных систем «сливатся» в единое пространство (Data Lake).
Интеграция приложений – это использование функций одних приложений другими приложениями. Осуществляется следующими методами:
📍Интерфейсы прикладного программирования (API) - набор функций, который программист может использовать для доступа к данным и алгоритмам программ;
📍 Обмен сообщениями (Корпоративная сервисная шина) – промежуточный программный стой между приложениями, на котором происходит хранение актуальных данных и их обмен со всеми интегрируемыми приложениями;
📍 Сервис-ориентированная архитектура (SOA) – модульный подход к разработке ПО, базирующийся на использовании сервисов;
📍Интеграция пользовательских интерфейсов – интеграции UI компонентов за счет объединения их внешнего представления, а не логики или схем данных самих приложений.
Интеграция бизнес-процессов - это интеграция приложений, данных и людей, вовлеченных в определенный бизнес-процесс. Здесь речь больше идет о функциях сотрудников, не о программной среде. Например, слияние ролей менеджера по приему заказов с частью функций менеджера по поиску клиентов.
Сегодня поговорим о системном анализе, а именно об объектах и методах интеграции.☝🏻💻
➡️ Объект интеграции - компонент интегрируемых информационных систем. Объектами интеграции могут выступать:
📍 платформы (ОС Windows, ОС Linux, сервер Intel Xeon и т.п.);
📍 данные (БД, СУБД Oracle Database, Microsoft SQL Server и т.п.);
📍 приложения (сервер приложений Microsoft, Java Runtine Environment, бизнес-логика или интерфейс какого-то приложения и т.п.);
📍 бизнес-процессы (функции сотрудников).
👉🏻 Интеграция платформ - это установление взаимодействия между приложениями, работающими на различных платформах (например, между приложениями на Linux и Windows), а также обеспечение работы приложений, разработанных для одной платформы, на других платформах (например, приложений Windows на платформе Solaris).
➡️ Интеграция платформ осуществляется следующими методами:
📍 Удаленный вызов процедур (remote procedure call RPC, Web-сервисы, REST и др.);
📍 ПО промежуточного слоя (Microsoft.Net, Java Runtime);
📍 Виртуализация - технология программного представления виртуальной версии ИТ-продуктов.
Интеграция данных предполагает совместное использование данных различных систем.
Осуществляется следующими методами:
📍 Универсальный доступ к данным - например, есть две БД, мы интегрируем одну со второй так, что первая получает всю необходимую информацию со второй по средствам запросов на выборку данных;
📍 Хранилища данных – информация с нескольких информационных систем «сливатся» в единое пространство (Data Lake).
Интеграция приложений – это использование функций одних приложений другими приложениями. Осуществляется следующими методами:
📍Интерфейсы прикладного программирования (API) - набор функций, который программист может использовать для доступа к данным и алгоритмам программ;
📍 Обмен сообщениями (Корпоративная сервисная шина) – промежуточный программный стой между приложениями, на котором происходит хранение актуальных данных и их обмен со всеми интегрируемыми приложениями;
📍 Сервис-ориентированная архитектура (SOA) – модульный подход к разработке ПО, базирующийся на использовании сервисов;
📍Интеграция пользовательских интерфейсов – интеграции UI компонентов за счет объединения их внешнего представления, а не логики или схем данных самих приложений.
Интеграция бизнес-процессов - это интеграция приложений, данных и людей, вовлеченных в определенный бизнес-процесс. Здесь речь больше идет о функциях сотрудников, не о программной среде. Например, слияние ролей менеджера по приему заказов с частью функций менеджера по поиску клиентов.
⭐️ Напоминаем, что остались последние деньки стать системным аналитиком в компании Andersen и получить хороший sign-on bonus💰💰
Программа "SA hiring days! Получи Job Offer в 3 шага!" заканчивается уже 30ого ноября.
☝🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
Программа "SA hiring days! Получи Job Offer в 3 шага!" заканчивается уже 30ого ноября.
☝🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/