https://www.perplexity.ai
промт — Выдели основные мысли
Answer
Основные мысли из видео о внедрении IT-проектов и автоматизации бизнес-процессов:
Ключевые этапы успешного проекта
- Определение проблемы:
- Начальный этап заключается в четком понимании проблемы, которую необходимо решить. Цели должны быть конкретными и измеримыми, например, сокращение времени на обработку заявок или увеличение прозрачности рекламных затрат.
- Поиск и выбор решения:
- Необходимо составить список требований к программному продукту и исследовать доступные решения на рынке. Важно отсеять варианты, которые не соответствуют более чем 30% ваших требований.
- Предпроектное обследование:
- На этом этапе происходит детальное обсуждение функциональных требований с поставщиками, что помогает оценить бюджеты и сроки доработок.
- Подготовка технического задания (ТЗ):
- ТЗ должно четко описывать все изменения и настройки системы. Важно задавать много вопросов для понимания деталей и избегания недоразумений.
- Разработка и синхронизация:
- Регулярные встречи с командой разработчиков (раз в две недели) помогают контролировать процесс разработки и своевременно выявлять проблемы.
- Тестирование:
- Необходимо проверить, что система работает согласно ТЗ. Тестирование должно включать сценарии использования системы реальными пользователями.
- Подготовка к запуску:
- Обучение сотрудников и перенос исторических данных в новую систему критически важны для успешного старта.
- Запуск проекта:
- В день запуска важно иметь поддержку разработчиков для быстрого решения возникающих проблем.
- Техническая поддержка и развитие:
- После запуска начинается этап постоянной поддержки, где учитываются отзывы пользователей для дальнейшего улучшения системы.
Эти этапы формируют основу для успешного внедрения IT-проектов, минимизируя риски провала и увеличивая шансы на достижение поставленных целей.
Расшифровка видео
0:00
Представьте что 70% it проектов
0:02
заканчиваются провалом это реально
0:04
почему так происходит как избежать
0:06
ошибок чтобы ваш проект не пополнил ряды
0:09
этой удручающее статистики в этом видео
0:11
я проведу вас по всем этапам от идеи До
0:13
завершения проекта постараюсь сделать
0:16
это на простом понятном языке без
0:18
сложных технических терминов Меня зовут
0:20
Александр Сидоров и уже больше 8ми лет я
0:22
внедряют автоматизации бизнес-процессов
0:24
для среднего крупного бизнеса
0:26
оставайтесь со мной чтобы узнать как ваш
0:28
проект может стать тем самым успешным
0:30
исключением обычно самую важную часть
Определите проблему, которую будете решать
0:32
всегда оставляют на конец видео но
0:34
конкретно в данном случае первый этап
0:36
является самым ключевым смотрите перед
0:38
покупкой и внедрением любого
0:40
программного продукта очень важно
0:42
задуматься О следующей вещи это зачем вы
0:45
вообще всё это делаете это должна быть
0:47
какая-то очень конкретная понятная
0:49
измеримая вещь не какие-то абстрактные
0:51
истории мы покупаем CRM чтобы увеличить
0:54
продажи Ну понятно что все хотят
0:56
увеличить продажи Но вам нужны какие-то
0:58
более конкретные вещи ну при пример нам
1:00
нужно ускорить Процесс формирования
1:03
договора и выставления счёта сейчас его
1:05
делают 5 дней мы хотим делать за 2 дня
1:07
ну или самое банальное мы не знаем
1:09
сколько заявок приходит в отдел продаж
1:11
Мы хотим их посчитать чтобы понять как у
1:14
нас тратятся деньги на рекламу это
1:15
нормальные и понятные цели если у вас
1:17
будет такая цель то в конце процесса вы
1:20
сможете понять а получилось у вас или
1:22
нет потому что все вот эти абстрактной
1:24
истории мы купили программу и у нас
1:26
увеличились продажи нуно Они не работают
1:28
поэтому если у вас нет чёткой цели уже
1:30
на этом этапе Вы можете остановиться И
1:32
не заниматься ерундой потому что
1:34
вероятность успешного завершения проекта
1:36
без цели она равна нулю Окей отлично вы
Поиск и выбор решения автоматизации бизнес-процессов
1:39
зафиксировали себе проблему которую вы
1:41
хотите решать и дальше собственно говоря
1:43
надо искать какой-то софт который
1:45
собственно говоря будет этим заниматься
1:47
Здесь вы как правило идёте там в поиск
1:49
Яндекса YouTube и начинаете искать
1:52
какие-то программы которая решает ту
1:54
задачу которую вы для себя
1:56
сформулировали и здесь Для начала вам
1:57
нужно составить два списка первый — это
2:00
собственно говоря список каких-то вот
2:03
требований да то есть Что вы хотите от
2:04
этого продукта да то есть общую цель мы
2:06
сформировали А теперь мы формируем то
2:08
что нам надо уже в таких деталях там Я
2:11
хочу чтобы было пять Воронок продаж или
2:13
Я хочу чтобы была интеграция с
2:14
мессенджерами Я хочу чтобы был такой-то
2:16
интерфейс Ну какие-то вот требования к
2:18
продукту это в первом списке и во втором
2:20
списке те решения которые есть на рынке
2:22
и потом сводите в таблицу Где у вас в
2:24
строках ваши требования а в заголовках
2:26
столбцов там уже те решения которые вы
2:29
нашли Ну а дальше вы уже связываетесь с
2:30
поставщиками этих решений И ставите
2:32
плюсики минуси там ну или баллы как все
2:34
эти продукты закрывают ваши требования
2:36
дальше Вы отсекает те решения которые
2:39
покрывают менее 70% ваших требований у
2:42
вас должно остаться там одно два или три
2:44
Ну и дальше выходите на переговоры с
Предпроектное обследование (ППО)
2:46
ними Итак вы связались там с тремя
2:49
поставщиками программы и собственно
2:51
начинаете предъявлять им ваши вот эти
2:53
функциональные требования которые вы
2:55
написали и обсуждать с ними как это всё
2:57
можно реализовать понятно что 70% у уже
3:00
доступны вам в каком-то базовом виде уже
3:03
внутри тех решений которые вы выбираете
3:05
но остаётся 30% ваших требований которые
3:08
необходимо доработать и здесь те
3:10
поставщики которых вы собственно говоря
3:11
выбрали они начнут подключать своих
3:13
технологических партнёров таких как мы
3:15
например и дальше эти партнёры будут
3:17
связываться с вами и проводить некое
3:19
предпроектное обследование для того
3:21
чтобы хотя бы примерно оценить бюджеты
3:24
сроки вот тех доработок которые вы
3:26
хотите или которые необходимо сделать
3:28
потому что они не покрывают
3:30
базовым продуктом этот этап может
3:32
длиться до месяца и по сути это является
3:34
отправной точкой Когда вам предстоит
3:36
принять решение начинается проект или не
3:39
начинается и выбрать кто будет его
3:41
реализовывать и на каком программном
3:43
продукте здесь важно максимально полно
3:46
рассказать вот этим вот технологическим
3:48
партнёрам которые будут с вами
3:49
разговаривать а что вы собственно говоря
3:51
хотите получить в итоге и вся суть
3:53
предпроектного обследования заключается
3:55
в том что сотрудники вот этих
3:56
технологических партнёров приходят к вам
3:58
и начинают спрашивать ваши подразделения
4:01
или департаменты на предмет того что и
4:04
как должно работать как выглядят ваши
4:06
текущие бизнес-процессы Что делают
4:09
сотрудники разных должностей Как они это
4:11
делают какие у вас документы должны
4:13
появляться что отправляется клиенту
4:15
Какие системы у вас уже есть с которыми
4:18
нужно будет соединиться и
4:19
взаимодействовать и здесь важно дать
4:21
максимально полную информацию Потому что
4:24
от этого будет зависеть оценка стоимости
Реклама моей компании по внедрению CRM/Service Desk
4:26
и срок Ну а я и моя команда уже с 2017
4:29
года реализуем CRM сес desk либо другие
4:32
системы по автоматизации
4:33
бизнес-процессов на одной из лучших
4:35
платформ на рынке России bpm Soft за это
4:38
время мы сделали кучу крутых решений вот
4:40
для Этих клиентов они сейчас здесь
4:41
появятся Поэтому если вам нужно
4:43
реализовать какую-то автоматизацию
4:45
вашего бизнеса ссылочка на Telegram
4:47
будет в описании оставляйте там заявку я
4:50
свяжусь с вами и расскажу можем мы вам
4:52
помочь или нет И если не можем то
4:54
подскажу куда Вам лучше идти за решением
4:56
вашей задачи после того как вы выберете
Как подготовить техническое задание (ТЗ)
4:58
программный продукт и партнёра который
5:00
вы будет реализовывать начнётся стадия
5:02
написания технического задания что это
5:04
такое Это такой документ который
5:06
описывает что в вашей системе будет
5:09
настроено доработано изменено что
5:12
конкретно получится на выходе и это
5:15
очень важный этап тут можно наделать
5:17
кучу ошибок Если что у меня есть
5:19
отдельное видео по ошибкам в ТЗ там я
5:22
ссылочку в описании прикреплю Но идея в
5:24
том что На этом этапе нужно быть очень
5:26
внимательным дотошный задавать много
5:28
вопросов и самое важное что вы должны
5:31
абсолютно чётко понимать что находится в
5:34
том документе который вам принесут на
5:36
согласование то есть сотрудники вашего
5:38
технологического партнёра будут
5:40
углублённо опрашивать тех людей которые
5:42
отвечают за те или иные процессы в
5:44
компании и собственно говоря формировать
5:46
Этот документ и ваша задача спрашивать в
5:48
любой момент когда вам что-то непонятно
5:51
и если большой проект то про то о чём вы
5:53
договаривались на словах могут забыть А
5:55
вот то что останется в документе про это
5:57
забыть не получится от качества
5:59
подготовки технического задания по сути
6:01
зависит весь дальнейший проект Какая
6:03
тонкость здесь есть скорее всего деньги
6:05
за написание ТЗ с вас будут брать по
6:07
какой-то почасовой ставке потому что
6:09
никто заранее скорее всего не скажет
6:11
сколько Это займёт времени поэтому очень
6:13
важно соблюсти баланс между детальность
6:16
ТЗ и длительностью его написания Ну
6:19
просто будет странно год его писать
6:21
потратить 10 млн рублей и уже всех тому
6:23
времени забудут зачем это всё было нужно
6:25
и что за ТЗ готовит поэтому смотрим
6:27
внимательно но не упа и са са главное
6:30
задавайте вопросы чтобы вам объяснили
6:32
что именно означает каждая деталь в этом
6:35
получившемся документе нужно понимать
6:37
что согласовывать отлично ТЗ написано
Непосредственно разработка
6:40
согласовано всеми участниками Будем
6:43
надеяться что все его поняли одинаково и
6:45
начинается этап Когда разработчики
6:47
уходят и начинают дописывать и
6:49
собственно говоря реализовывать то что
6:51
написано в ТЗ настраивать необходимые
6:53
настройки Ну в общем процесс реализации
6:55
пошёл и здесь очень важный момент что
6:58
нужно заранее
6:59
с командой разработчиков что максимум
7:01
раз в 2 недели вы будете встречаться и
7:03
синхронизироваться по тому как
7:05
собственно говоря идёт процесс
7:06
разработки это называется статусные
7:08
встречи это позволяет вам сохранить
7:10
контроль над проектом И что самое важное
7:13
вовремя увидеть если что-то пойдёт не
7:16
так потому что кто-то что-то может
7:18
трактовать по-другому чем написано в ТЗ
7:21
или в ТЗ была какая-то допущена ошибка
7:23
или в процессе реализации выявилось то
7:25
что в ТЗ вообще не учли и вот эту не
7:28
учтён важно вовремя вать и
7:30
корректировать чтобы в конце разработки
7:32
не столкнуться с классической проблемой
7:34
Ну в ТЗ было так написано мы так и
7:36
сделали не хотите так проводите встречи
7:38
с разработкой раз в 2 недели они тоже
7:40
заинтересованы в том чтобы успешно
7:42
завершить проект и сдать вам это Готовое
7:44
решение для того чтобы получить доступ к
7:48
последнему этапу Я о нём расскажу в
Как лучше тестировать?
7:50
самом конце А дальше проект переходит в
7:52
фазу тестирования очень важная штука по
7:55
большому счёту На этом этапе необходимо
7:57
проверить что всё что было заложено на
7:59
на этапе технического задания работает
8:01
ровно так как и написано видов
8:03
тестирования на самом деле много но если
8:05
не углубляться в технические подробности
8:07
самым простым способом протестировать
8:10
какое-то готовое уже решение это на
8:12
этапе технического задания прописать
8:15
несколько сценариев как сотрудники будут
8:17
использовать ту программу которую вы
8:19
внедряется Я как менеджер отдела продаж
8:21
захожу в эту карточку нажимаю эту кнопку
8:23
система делает то-то распечатывает мне
8:25
такой документ Ну или какие-то другие
8:27
сценарии которые характерны там для
8:29
вашего предприятия как правило
8:30
тестирование производит тот кто
8:32
собственно говоря разрабатывал вам всё
8:34
это но иногда и сотрудники заказчика
8:36
тоже присоединяются на этом этапе здесь
8:38
есть тонкий момент любой разработчик на
8:40
этом этапе будет проверять что Готовое
8:42
решение соответствует тому что написано
8:44
в ТЗ этот процесс как правило лежит не в
8:46
плоскости нравится или не нравится а в
8:48
плоскости соответствует ТЗ или не
8:50
соответствует если взаимодействие между
8:52
разработчикам и заказчикам на протяжении
8:55
проекта было минимально Вот на этом
8:57
этапе может выяви несоответствие
8:59
ожиданий заказчика к тому что написано в
9:01
ТЗ и то что он построил себе в голове и
9:04
это одна из точек где проект Может
9:05
начать разваливаться поэтому обращайте
Подготовка к запуску (ОЭ)
9:07
всегда на неё внимание Дальше я бы
9:08
выделил такой этап как подготовка к
9:11
запуску Ну он может звучать в разных
9:13
формулировках но по сути это подготовка
9:14
к переходу в режим полноценного
9:16
использования На этом этапе важно
9:18
обучить всех сотрудников которые будут
9:20
использовать систему тому как ей
9:23
собственно говоря пользоваться Потому
9:24
что если они не знают как это
9:26
использовать то в первый день запуска Ну
9:28
собственно говоря на этом всё и
9:29
закончится То есть это должен быть
9:31
какой-то системный процесс да собираются
9:33
группы там по линейному персоналу и
9:35
обучаются в группах руководители могут
9:37
обучаться индивидуально потому что у них
9:39
как правило несколько в другом разрезе
9:41
идёт обучение но важно чтобы все
9:43
понимали как этим пользоваться и что с
9:46
этим Совсем делать также На этом этапе
9:48
происходит дозагрузка каких-то
9:50
исторических данных Ну например если
9:52
раньше люди работали в какой-то Старой
9:54
системе сейчас переезжают в Новую
9:56
соответственно данные из старой системы
9:58
нужно забрать и положить в новую систему
10:00
на этом этапе нужно проверить что все
10:02
понимают как системой пользоваться что
10:04
все ваши исторические данные загружены
10:06
интеграции настроены то есть всё О’КЕЙ в
10:09
системе можно садиться и начинать
10:11
работать проще говоря нужно чтобы все
10:13
понимали что им нужно делать Когда
10:15
настанет Час X и произойдёт сам
Начало реального использования (промышленная эксплуатация)
10:17
непосредственно запуск Ну что вот и
10:18
настаёт день X собственно момент запуска
10:21
это та точка с которой начинается уже
10:23
такая Боевая эксплуатация системы то
10:26
есть назначается какой-то день условно
10:28
там с понель или с первого числа когда
10:31
все сотрудники приходят с утра на
10:32
рабочее место и открывают уже интерфейс
10:35
новой системы Если вы дошли до этого
10:37
момента то провалить проект уже
10:39
достаточно сложно но всё равно подводные
10:41
камни здесь есть этот этап происходит
10:44
обязательно с участием тех разработчиков
10:46
которые делали вам систему то есть они в
10:49
прямом смысле должны быть там в онлайне
10:51
у вас на связи или у вас в офисе Как вы
10:54
договоритесь и быть готовыми поддержать
10:56
пользователей если у них что-то пойдёт
10:58
не штат потому что очень часто история
11:00
когда тестирование всё проведено всё
11:02
хорошо всё соответствует но в реальной
11:04
работе начинают вскрывать какие-то
11:07
неучтённый мелочи которые необходимо
11:09
быстро править и нужно всегда на этот
11:11
этап закладывать какие-то резервы там по
11:14
своим ресурсам сотрудникам подрядчикам
11:18
которые могут быстро вас поддержать и
11:20
собственно говоря поправить те нюансы
11:22
которые будут возникать опять же скорее
11:24
всего вы вряд ли тестировали на том
11:27
количестве пользователей которые у вас в
11:29
систему Я имею в виду то что тупо в
11:31
систему зашло гораздо больше
11:33
пользователей чем при тестировании это
11:35
тот момент когда вскроется какие-то
11:37
подводные камни что руководители на
11:39
самом деле не знают как работают их
11:42
сотрудники на этом этапе нужно учитывать
11:44
что неделю две три месяц и так далее ну
11:47
какой-то срок будет такой процесс
11:49
турбулентности резкий негатив от
11:51
сотрудников Ну просто потому что у них
11:52
происходит какие-то изменения а люди не
11:54
любят изменения И в этот момент те люди
11:56
которые работают с новой системой начнут
11:58
Гене вать какие-то свои идеи пожелания
12:01
недовольства и очень важно их все
12:03
записать куда-нибудь отдельную табличку
12:05
листочек бумажку неважно просто запишите
12:07
их просто Потому что когда люди работают
12:09
к этому всё равно придётся вернуться так
Тех поддержка и развитие
12:11
отлично всё запустило ничего не рухнуло
12:13
люди начинают работать вроде всё
12:15
более-менее окей тут начинается такой
12:17
условно бесконечный этап это техническая
12:19
поддержка и развитие и скорее всего этот
12:22
этап продлится столько лет сколько вы
12:23
будете пользоваться внедренной вами
12:26
системой теперь пришло время взять те
12:28
хотелки желания и претензии которые вам
12:30
сформировали сотрудники в момент запуска
12:32
и посовещались имеет смысл их делать не
12:35
имеет В какой последовательности
12:37
разумные они разумные полезные для
12:39
бизнеса или неполезные Это то что
12:41
касается развития проекта потому что
12:43
любая компания она меняется у неё
12:45
меняются бизнес-процессы и все те
12:47
системы которые вы покупаете внедряется
12:49
их придётся подстраивать под вот эти вот
12:51
новые изменения которые 100% будут
12:53
появляться в компании Ну и техническая
12:55
поддержка — это как правило некий набор
12:57
гигиенических процедур какой-то по
12:59
конечным пользователем который есть Ну в
13:01
любом it продукте его можно воспринимать
13:04
как некое то для автомобиля Ну в любом
13:06
случае всем потребуется окно чтобы вы
13:09
понимали а к кому вы можете обратиться
13:11
чтобы вам ответили на ваши вопросы
13:13
почему это так работает Зачем так
13:15
сделали там почему это перестало
13:17
работать и если развитие платформы
13:19
скорее всего останется за теми
13:20
разработчиками которые вам всё это
13:22
делали то вот функцию поддержки вы в
13:25
принципе можете организовать у себя на
13:26
стороне потому что по большей части это
13:28
какие-то запросы которые реально могут
13:30
делать ваши опытные сотрудники которые
13:33
глубже познакомились с системой Ну либо
13:35
специально выделенный человек или
13:37
команда которую вы на это подрядились
13:38
что всё получилось Меня зовут Александр
13:41
Сидоров пока