pipeline что это такое

Пайплайн

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

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

Пайплайн в продажах

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

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

Если пайплайн сделан хорошо, он позволит:

Отличия воронки продаж от пайплайна

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

Как использовать пайплайн продаж в CRM

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

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

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

Аналитика пайплайна

Правильный пайплайн позволяет оценить:

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

Как создать свой пайплайн: этапы создания

Идеальный пайплайн состоит из пяти этапов, каждый из которых помогает визуализировать процесс трансформации покупателя:

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

Как использовать пайплайн на практике

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

Заключение

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

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

Источник

Руководство для начинающих: создаем DevOps-пайплайн

Если вы новичок в DevOps, взгляните на эту инструкцию по созданию вашего первого конвейера из пяти этапов.

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

Мое путешествие по DevOps

Раньше я работал в облачной команде Citi Group, разрабатывая веб-приложение Infrastructure-as-a-Service (IaaS) для управления облачной инфраструктурой Citi, но меня всегда интересовало, как сделать процесс развития более эффективным и привнести позитивные культурные изменения в команду разработчиков. Ответ я нашел в книге, рекомендованной Грегом Лавендером (Greg Lavender), техническим директором Citi по облачной архитектуре и инфраструктуре. Книга называлась «Проект Феникс» (The Phoenix Project), и в ней объясняются принципы DevOps, при этом она читается как роман.

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

Amazon: 23 000 в день
Google: 5 500 в день
Netflix: 500 в день
Facebook: Раз в день
Twitter: 3 раза в неделю
Типичная компания: Раз в 9 месяцев

Как вообще возможны частоты Amazon, Google и Netflix? Все потому, что эти компании придумали, как сделать почти идеальный DevOps-конвейер.

Мы были далеки от этого, пока не внедрили DevOps в Citi. Тогда в моей команде были разные окружения, но развертывание на сервере разработки было полностью ручным. Все разработчики имели доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. Проблема заключалась в том, что сервер выключался всякий раз, когда несколько пользователей одновременно пытались выполнить развертывание, поэтому разработчики должны были сообщать друг другу о своих намерениях, что было довольно болезненно. Кроме того, существовали проблемы с низкоуровневым тестовым покрытием кода, громоздкими процессами ручного развертывания и отсутствием возможности отслеживать развертывание кода, связанного с определенной задачей или пользовательской историей.

Я понял, что нужно что-то делать, и нашел коллегу-единомышленника. Мы решили сотрудничать в создании первоначального DevOps-конвейера – он установил виртуальную машину и сервер приложений Tomcat, пока я работал над Jenkins, интегрировал Atlassian Jira и BitBucket, а также работал над тестовым покрытием кода. Этот сайд-проект был очень успешным: мы почти полностью автоматизировали многие процессы, достигли практически 100% работоспособности нашего сервера разработки, обеспечили отслеживание и улучшили тестовое покрытие кода, а также добавили возможность связывать ветки в Git с задачами в Jira или развертыванием. Большинство инструментов, которые мы использовали для построения нашего конвейера DevOps, имели открытый исходный код.

Теперь я понимаю, насколько простым был наш DevOps-пайплайн: мы не использовали расширения вроде Jenkins files или Ansible. Однако, этот простой конвейер работал хорошо, возможно, благодаря принципу Парето (также известному как правило 80/20).

Краткое введение в DevOps и пайплайн CI/CD

Если вы спросите несколько человек: «Что такое DevOps?», то вы, вероятно, получите несколько разных ответов. DevOps, как и Agile, развивался, чтобы охватить множество различных дисциплин, но большинство людей согласятся с некоторыми вещами: DevOps — это практика разработки программного обеспечения или жизненный цикл разработки программного обеспечения (SDLC), центральным принципом которой является изменение культуры, в которой разработчики и не-разработчики существуют в среде, в которой:

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

Хотя наличие правильных программных инструментов — не единственное, что нужно для создания среды DevOps, некоторые инструменты необходимы. Ключевой инструмент – непрерывная интеграция и непрерывное развертывание (CI/CD). В этом конвейере среды имеют различные стадии (например, DEV, INT, TST, QA, UAT, STG, PROD), многие операции автоматизированы, а разработчики могут писать высококачественный код, добиваться гибкости разработки и высокой частоты развертываний.

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

Шаг 1: Методы CI/CD

Первое, что вам нужно – инструмент для CI/CD. Jenkins, инструмент с открытым исходным кодом, основанный на Java, и распространяемый по лицензии MIT, является тем средством, которое популяризировало направление DevOps и стало стандартом де-факто.

Так что же такое Jenkins? Считайте, что это некий волшебный универсальный пульт дистанционного управления, который может разговаривать с различными службами и инструментами и организовывать их. Сам по себе CI/CD инструмент, такой как Jenkins, бесполезен, но он становится более мощным по мере того, как подключается к различным инструментам и сервисам.

Jenkins – всего лишь один из многих инструментов с открытым исходным кодом для CI/CD, который вы можете использовать для построения DevOps-пайплайна.

Jenkins: Creative Commons and MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Вот как выглядят DevOps-процессы с инструментом CI/CD:

У вас есть инструмент CI/CD, работающий на вашем локалхосте, но на данный момент вы мало что можете сделать. Давайте перейдем на следующий этап путешествия в мир DevOps.

Шаг 2: Управление системами контроля исходного кода

Лучший (и, возможно, самый простой) способ проверить, что ваш инструмент CI/CD может творить магию – интегрироваться с инструментом контроля исходного кода (SCM). Зачем вам нужен контроль над исходным кодом? Предположим, вы разрабатываете приложение. Всякий раз, когда вы создаете приложение, вы программируете, и неважно, используете вы Java, Python, C++, Go, Ruby, JavaScript или какой-нибудь из газиллионов языков программирования. Код, который вы пишете называется исходным кодом. В начале, особенно когда вы работаете в одиночку, вероятно, можно поместить все в локальную директорию. Но когда проект становится больше, и вы приглашаете других людей к сотрудничеству, вам нужен способ предотвращения конфликтов при эффективном обмене модификациями. Вам также нужен способ восстановления предыдущих версий, потому что создание бекапов и копирование/вставка в них уже устаревает. Вам (и вашим товарищам по команде) нужно что-то получше.

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

Хотя существует множество инструментов контроля исходного кода, Git является стандартом, и это верно. Я настоятельно рекомендую использовать Git, хотя, если угодно, есть и другие варианты с открытым исходным кодом.

Git: GPLv2 и LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Так выглядит DevOps-пайплайн с добавлением средств контроля исходного кода.

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

Шаг 3: Создание инструмента автоматизации сборки

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

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

Здорово! Вы можете поместить файлы конфигурации инструмента автоматизации сборки в систему управления исходным кодом и позволить вашему инструменту CI/CD собрать все воедино.

Все хорошо, не так ли? Но где развернуть ваше приложение?

Шаг 4: Сервер для веб-приложений

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

Сервер для веб-приложений представляет собой именно такой контейнер. Сервер обеспечивает среду, в которой может быть определена логика развертываемого пакета. Также сервер предоставляет интерфейс и предлагает веб-сервисы, открывая сокеты для внешнего мира. Вам нужен HTTP-сервер, а также некоторая среда (например, виртуальная машина) для его установки. А пока, давайте предположим, что вы узнаете об этом дальше (хотя я расскажу о контейнерах ниже).

Существует несколько серверов для веб-приложений с открытым исходным кодом.

Ваш DevOps-пайплайн почти готов к использованию. Хорошая работа!

Хотя на этом можно остановиться и заниматься интеграцией самостоятельно, качество кода – важная вещь для разработчика приложений, и об этом нужно беспокоиться.

Шаг 5: Покрытие тестирования кода

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

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

Системы тестирования кода

Системы рекомендаций по улучшению кода

Обратите внимание, что большинство инструментов и фреймворков, упомянутых выше, написаны для Java, Python и JavaScript, поскольку C++ и C# являются проприетарными языками программирования (хотя GCC и имеет открытый исходный код).

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

Дополнительные шаги

Как я уже говорил, вы можете размещать свой сервер на виртуальной машине или сервере, но контейнеры являются популярным решением.

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

Хотя существуют и другие варианты контейнеров, наиболее популярными являются Docker и Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Промежуточные средства автоматизации

Наш DevOps-пайплайн в основном ориентирован на совместное создание и развертывание приложений, но существует множество других вещей, которые можно сделать с помощью DevOps-инструментов. Одной из них является использование инструментов Infrastructure as Code (IaC), которые также известны как средства промежуточной автоматизации. Эти инструменты помогают автоматизировать установку, управление и другие задачи для промежуточного программного обеспечения. Так, например, инструмент автоматизации может извлекать приложения вроде сервера веб-приложений, базы данных и инструмента мониторинга, с правильными конфигурациями и развертывать их на сервере приложений.

Вот несколько инструментов промежуточной автоматизации с открытым исходным кодом:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache или GPL

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

Источник

Pipeline в продажах

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

Удобный инструмент для этого – перечень сделок, который в реальном времени ведут сотрудники, и могут в любой момент предъявить для проверки. Такой список носит название pipeline, что в переводе означает «трубопровод».

Что такое pipeline

В процедуре менеджмента pipeline рассматривается как первичный источник информации. Он одновременно является рабочим документом и отчетом о деятельности.

В нем приводится перечень сделок или процессов, проведенных менеджером. Здесь отражаются все сделки независимо от стадии их прохождения: от звонка и до факта оплаты.

Pipeline имеет форму таблицы, в которой перечисляются:

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

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

Фактически pipeline – это динамическая воронка продаж, которая постоянно изменяется, регистрируя все этапы деятельности.

Этапы pipeline

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

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

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

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

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

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

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

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

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

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

Такие приемы малозатратные для продавца, но эффективно воздействуют на покупателя, нужно только правильно оценить его интересы и предложить соответствующий продукт:

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

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

Применение pipeline в CRM

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

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

Основные показатели, которые присутствуют в отчете:

Информация в pipeline соответствует уровням воронки продаж и выглядит примерно таким образом:

С каждым последующим этапом количество потенциальных клиентов сокращается. Так из 500 холодных звонков реальная продажа может состояться в 2–3 случаях.

Источник