Read the book: «1С-аналитик с нуля. Практическое руководство для начинающих»
От автора
Я не программист. Несколько лет я проработала в сфере налогов и учёта, потом сменила профессию совсем — стала шеф-поваром. И там, и там я на практике занималась тем, что эта книга называет мышлением аналитика, просто не знала этого слова: разбиралась, откуда берётся хаос в процессе, задавала вопросы, выстраивала порядок там, где его не было. Сейчас я целенаправленно перехожу в 1С-аналитику — учусь, разбираю кейсы, готовлюсь к первому проекту.
Когда я начала разбираться в теме, первое, с чем я столкнулась: почти все материалы про 1С написаны для тех, кто уже что-то понимает в IT. Термины объясняются через другие термины. Примеры — абстрактные. А главный вопрос новичка — «а как это выглядит на самом деле, в реальной работе?» — остаётся без ответа.
Эта книга — то пособие, которое я хотела бы иметь сама в первый день. Здесь нет лишней теории ради теории. Основная сквозная история книги — группа компаний «БизнесПлюс» с её магазинами, складом и производством: вы встретите одних и тех же людей и одни и те же проекты из главы в главу. Часть примеров и упражнений построена на других кейсах — медицинском центре «МедЛайн», сервисной компании «СервисПлюс» — чтобы показать, что подход аналитика работает в любой сфере, а не только в рознице.
Если вы — бухгалтер, повар, менеджер, специалист без технического образования, который хочет работать головой и войти в профессию, где ценится умение думать, а не только умение нажимать кнопки, — эта книга для вас.
Введение: как пользоваться этой книгой
Кому подходит эта книга. Junior без опыта в IT, который хочет системно понять профессию 1С-аналитика — от базовых понятий до подготовки к первому собеседованию.
Чего в ней нет. Это не учебник по программированию 1С и не курс по настройке конфигураций. Здесь вы не научитесь писать код — вы научитесь мыслить как аналитик и ставить задачи тем, кто пишет код.
Как построена книга. Десять глав с основным сквозным примером — группой компаний «БизнесПлюс», и дополнительными кейсами из других сфер для практики. Каждая глава:
●
объясняет одну ключевую тему через теорию и живые примеры;
●
показывает типичные ошибки новичков;
●
даёт практический кейс и упражнения;
●
заканчивается контрольными вопросами, разбором вопросов с собеседований и блоком самопроверки.
Как читать. Не пропускайте упражнения и самопроверку — именно они превращают чтение в понимание. Если галочка в самопроверке не ставится уверенно — вернитесь к разделу, прежде чем идти дальше. Главы построены последовательно: каждая следующая опирается на предыдущую.
Структура книги:
1. Кто такой 1С-аналитик и зачем он нужен
2. Участники проекта внедрения 1С — кто есть кто
3. Бизнес-процесс — что это и зачем аналитику его понимать
4. Интервью с заказчиком — как задавать правильные вопросы
5. Аналитическое расследование — как найти настоящую проблему
6. Требования — что это и как их собирать
7. Основы тестирования
8. Документы аналитика — что и зачем писать
9. Первый проект — как выжить и не потеряться
10. Подготовка к собеседованию на Junior 1С-аналитика
Профессия аналитика начинается не с изучения 1С, а с одной привычки — не соглашаться с первым объяснением и спрашивать «а что на самом деле происходит?». Дальше — десять глав, которые превратят эту привычку в рабочий навык.
Начнём.
Глава 1
Кто такой 1С-аналитик и зачем он нужен
Часть I. Мышление аналитика
Зачем читать эту главу
Прежде чем учиться работать аналитиком — нужно понять, кем ты становишься. Многие люди приходят в профессию с размытым представлением: «что-то связанное с 1С, что-то между бухгалтером и программистом». Это опасное заблуждение. Оно приводит к тому, что человек либо уходит в программирование, либо застревает в роли продвинутого пользователя и никогда не вырастает в настоящего аналитика.
После этой главы ты будешь знать:
●
кто такой 1С-аналитик
●
чем он занимается каждый день
●
чем он отличается от программиста и консультанта
●
почему эта профессия востребована
●
как выглядит твой карьерный путь
Центральная идея главы
Аналитик — это переводчик.
Он переводит язык бизнеса на язык системы, и язык системы — обратно на язык бизнеса.
Бизнес говорит: «Нам нужно видеть, какой менеджер сколько продал за месяц». Система не понимает этого. Система понимает объекты, регистры, запросы, отчёты. Аналитик стоит между ними. Он слышит бизнес, понимает систему, и строит между ними мост.
Теория
Что такое 1С-аналитик
1С-аналитик — это специалист, который участвует во внедрении и развитии информационных систем на платформе 1С. Его главная задача — понять, что нужно бизнесу, и помочь реализовать это в системе.
Обрати внимание: не запрограммировать самому. Не нажать кнопки в 1С. А понять потребность и организовать её реализацию. Это принципиальное отличие.
Что аналитик делает на практике
Вот реальный рабочий день аналитика — без прикрас.
Утро. Встреча с директором магазина сети «Стиль» из группы компаний «БизнесПлюс». Директор жалуется: «Кассиры тратят по три минуты на оформление возврата. Очередь растёт. Клиенты уходят».
Аналитик не говорит: «Сейчас всё починим». Аналитик задаёт вопросы:
●
Как сейчас выглядит процесс возврата шаг за шагом?
●
Где именно теряется время?
●
Это происходит во всех магазинах или в одном?
●
Как должно быть в идеале?
Это называется сбор требований — одна из ключевых задач аналитика.
День. Аналитик описывает процесс возврата текстом и схемой. Фиксирует, что именно должна делать система. Этот документ называется техническое задание или постановка задачи.
Вечер. Аналитик передаёт постановку задачи программисту. Объясняет логику. Отвечает на вопросы. Потом проверяет результат — совпадает ли то, что сделал программист, с тем, что хотел бизнес. Это называется тестирование и приёмка.
Чем аналитик отличается от других специалистов
Это важно знать, потому что на собеседовании этот вопрос задают почти всегда.
Специалист
Его главная задача
Программист 1С
Пишет код. Реализует то, что ему поставили.
Консультант 1С
Обучает пользователей. Настраивает типовые функции.
Аналитик 1С
Понимает потребность бизнеса. Формулирует задачу. Контролирует результат.
Руководитель проекта
Управляет сроками, бюджетом, командой.
Аналитик не пишет код. Но он должен понимать, как система устроена — иначе он не сможет поставить задачу программисту.
Как это выглядит в виде схемы движения задачи:
Бизнес
↓
Аналитик
↓
Программист
↓
Система 1С
↓
Пользователь
Бизнес формулирует потребность. Аналитик превращает её в понятную задачу. Программист реализует задачу в системе. Пользователь получает результат в виде рабочего инструмента.
Почему профессия востребована
Внедрение 1С — это не установка программы. Это изменение того, как работает бизнес. Представь: компания «МебельПром» из группы «БизнесПлюс» решила автоматизировать производство. Раньше мастера вели учёт материалов в тетради. Теперь всё должно быть в 1С.
Программист может написать любой код. Но он не знает, как именно мастера считают расход материалов, какие исключения бывают, что делать с браком, как оформляется срочный заказ. Это знает аналитик. Он выясняет, описывает, структурирует — и только потом программист получает задачу, которую можно выполнить.
На сложных проектах хороший аналитик значительно снижает риск ошибок и дорогостоящих переделок. Именно поэтому спрос на хороших аналитиков стабильно высокий.
Карьерный путь
Junior-аналитик → Middle-аналитик → Senior-аналитик → Руководитель / Архитектор
[ вы здесь ]
Этот учебник готовит тебя к уровню Junior. Junior не обязан знать всё. Но он обязан уметь думать как аналитик.
Пример из жизни
Аналогия: дизайнер интерьера
Представь, что ты переезжаешь в новую квартиру и нанимаешь дизайнера интерьера. Ты говоришь: «Хочу уютно, светло, чтобы было место для книг». Дизайнер не идёт сразу к строителям с этими словами. Он задаёт вопросы: сколько людей живёт, есть ли дети, какой бюджет, нужен ли рабочий стол, какой стиль нравится. Потом делает проект — схему, визуализацию, список материалов. Только после этого строители получают конкретное задание.
Дизайнер = аналитик. Строители = программисты. Ты = бизнес.
Пример из 1С
Директор медицинского центра «МедЛайн» говорит: «Мы теряем пациентов, потому что запись на приём — это хаос. Операторы путаются, одно время записывают двух пациентов к одному врачу».
Программист слышит: «Нужно что-то написать про расписание» → Идёт писать код
Аналитик слышит: «Есть проблема — двойная запись. Нужно разобраться» → Как сейчас ведётся запись? Сколько врачей и кабинетов? Какова длительность приёма? Бывают ли исключения? Как должна выглядеть идеальная запись?
Результат: программист пишет именно то, что нужно. С первого раза.
Типичные ошибки новичка
Ошибка №1. «Я должен знать 1С как пользователь»
НЕВЕРНО: Изучать все меню и кнопки системы, думая, что это главное.
ВЕРНО: Аналитик должен понимать логику системы — как данные связаны. Знать наизусть все меню — не его задача.
Ошибка №2. «Аналитик — это почти программист»
НЕВЕРНО: Начинать учить язык программирования 1С в первую очередь.
ВЕРНО: Аналитик не пишет код. Он ставит задачи тому, кто пишет. Базовое понимание кода — полезно, но не первый приоритет.
Ошибка №3. «Заказчик сам знает, что ему нужно»
НЕВЕРНО: Сразу выполнять то, что просит заказчик, не уточняя.
ВЕРНО: Заказчик знает свою боль, но почти никогда не знает точного решения. Задача аналитика — найти решение и правильно его сформулировать.
Практический кейс
Ситуация
Ты — Junior-аналитик. Руководитель проекта говорит: «Съезди к директору магазина "Стиль". Он жалуется на что-то с отчётами. Разберись». Директор говорит: «Мне нужен отчёт по продажам».
Что делать дальше?
НЕВЕРНО: Идёшь к программисту и говоришь: «Сделай отчёт по продажам»
ВЕРНО: Задаёшь уточняющие вопросы: За какой период? В разрезе чего — товары, менеджеры? Какие показатели — количество, сумма, прибыль? В каком виде — таблица, Excel? Кто будет смотреть?
Так подобные уточнения обычно выглядят в рабочих заметках аналитика — не как красиво оформленный документ, а как короткая памятка для себя:
Рабочие заметки аналитика
Проблема: Оформление возврата занимает около 3 минут.
Что необходимо выяснить: • На каком этапе возникает задержка? • Во всех ли магазинах? • Как часто происходят возвраты? • Какой результат считается успешным?
Практические упражнения
1. Упражнение 1
Напиши своими словами: чем аналитик отличается от программиста? Объясни так, как объяснил бы другу, который ничего не знает об IT.
2. Упражнение 2
Вспомни ситуацию, когда кто-то сделал не то, что от него хотели. В чём была проблема? Как аналитик мог бы её предотвратить?
3. Упражнение 3
Директор склада «ТрансЛог» говорит: «Нам нужна автоматизация». Составь список из 5 уточняющих вопросов.
Ориентир для самопроверки
По этим вопросам сверь свои ответы — не как «правильно/неправильно», а как ориентир, куда двигаться дальше:
●
В упражнении 1 — звучит ли объяснение так, что его поймёт человек без опыта в IT, без единого термина, который тут же не расшифрован?
●
В упражнении 2 — назвал ли ты конкретный момент, где не хватило уточняющего вопроса, а не общее «нужно было лучше объяснить»?
●
В упражнении 3 — есть ли среди твоих пяти вопросов хотя бы один про исключения или нестандартные случаи, а не только про «как есть сейчас»?
Если на все три вопроса ответ «да» — двигайся дальше. Если хотя бы на один «нет» — вернись и договори мысль до конца, прежде чем читать разбор в следующей главе.
Контрольные вопросы
1. Кто такой 1С-аналитик и в чём его главная задача?
2. Чем аналитик отличается от программиста 1С?
3. Чем аналитик отличается от консультанта 1С?
4. Что такое сбор требований?
5. Что такое постановка задачи?
6. Почему нельзя сразу выполнять то, что просит заказчик?
7. Какие уровни есть в карьере 1С-аналитика?
8. Что должен уметь Junior-аналитик?
Что спрашивают на собеседовании
Это примеры вопросов, которые часто встречаются на собеседованиях Junior 1С-аналитиков.
Вопрос: Расскажите, как вы понимаете роль аналитика в проекте внедрения 1С.
Вопрос: Чем аналитик отличается от программиста?
Ответ Junior: Аналитик — это тот, кто общается с заказчиком и понимает, что нужно сделать. А программист это уже реализует в коде. Аналитик не программирует.
Ответ опытного аналитика: Программист решает техническую задачу — он получает чёткое описание того, что нужно реализовать, и пишет код. Аналитик работает на шаг раньше: он выявляет реальную потребность бизнеса, отделяет проблему от решения, формулирует требования. Без аналитика программист работает по принципу «сделай что-нибудь» — и в итоге переделки, потери времени и денег. Аналитик снижает эту неопределённость.
Вопрос: Что такое требования и зачем их собирать?
Ответ Junior: Требования — это то, что должна делать система. Их нужно записать, чтобы потом было что показать программисту.
Ответ опытного аналитика: Требования — точное, проверяемое описание того, что система должна делать. Их собирают, потому что без них программист и заказчик каждый представляют результат по-своему — и в итоге получают разное. Я собираю требования через интервью с ключевыми пользователями, уточняю неоднозначности, фиксирую письменно и согласовываю с заказчиком до начала разработки. Хорошее требование можно проверить: прочитав его, программист точно знает, что делать, а заказчик — что получит.
Вопрос: Заказчик говорит «сделайте мне отчёт по продажам». Ваши действия?
Ответ Junior: Уточню у заказчика, какие данные нужны в отчёте, и передам программисту.
Ответ опытного аналитика: Сначала пойму, зачем именно нужен этот отчёт — какое решение заказчик собирается принимать на его основе. Затем уточню: за какой период, в каком разрезе — по товарам, по менеджерам, какие показатели важны, кто и как часто будет им пользоваться. Часто за просьбой «отчёт по продажам» стоит конкретная проблема — например, директор не понимает, почему падает выручка. Если сформулировать отчёт неточно — придётся переделывать.
Итоговые выводы
●
1С-аналитик — переводчик между бизнесом и системой.
●
Его главный инструмент — умение задавать правильные вопросы.
●
Аналитик не программирует, но понимает логику системы.
●
Аналитик не выполняет пожелания заказчика автоматически — он выясняет реальную потребность.
●
Junior-аналитик готов работать под руководством, задавать вопросы и фиксировать результаты.
Мышление аналитика начинается с одного вопроса: «А зачем это нужно?»
От автора
Когда я только начинала разбираться в этой профессии, самым сложным было не выучить термины — а перестать сразу предлагать решение. Я много лет работала там, где от меня как раз ждали быстрых ответов: сказали — сделала. Привычка слышать проблему и сразу бежать её чинить оказалась ровно тем, от чего пришлось отучиваться в первую очередь. Если у тебя похожий опыт — не считай это недостатком. Считай это тем, что нужно осознанно перенастроить, и это получается у всех, кто даёт себе на это время.
Самопроверка
Прежде чем перейти к следующей главе — проверь себя. Поставь галочку напротив каждого пункта, если можешь ответить уверенно.
Я понимаю профессию
[ ] Я могу объяснить своими словами, кто такой 1С-аналитик — без заглядывания в текст.
[ ] Я понимаю, чем аналитик отличается от программиста.
[ ] Я понимаю, чем аналитик отличается от консультанта.
[ ] Я могу назвать главную задачу аналитика одним предложением.
Я понимаю мышление аналитика
[ ] Я понимаю, почему нельзя сразу выполнять то, что просит заказчик.
[ ] Я понимаю, что такое «отделить проблему от решения».
[ ] Я знаю, какой вопрос аналитик задаёт первым делом.
Я готов к практике
[ ] Если директор скажет «сделайте отчёт по продажам» — я знаю минимум пять уточняющих вопросов.
[ ] Я выполнил все три упражнения из главы.
Я готов к собеседованию
[ ] Я могу ответить на вопрос «Кто такой аналитик» так, как ответил бы опытный специалист.
[x] Все галочки стоят — Можно переходить к Главе 2
[ ] Есть непроставленные галочки — Вернись к соответствующему разделу. Не торопись — лучше понять сейчас, чем запутаться потом.
Глава 2
Участники проекта внедрения 1С — кто есть кто
Часть I. Мышление аналитика
Зачем читать эту главу
На своём первом проекте Junior-аналитик часто теряется. Вокруг много людей, у каждого своя роль, свои интересы, свои требования. Директор говорит одно, бухгалтер — другое, программист — третье. Кого слушать? Кому отвечать? С кем согласовывать?
Если не понимать, кто есть кто в проекте — аналитик превращается в почтальона, который носит сообщения между людьми, не понимая их смысла.
После этой главы ты будешь знать:
●
кто участвует в проекте внедрения 1С
●
какую роль играет каждый участник
●
чего хочет каждый участник
●
как аналитик работает с каждым из них
●
какие конфликты возникают между участниками и как их распознать
Центральная идея главы
У каждого участника проекта — своя картина мира.
Директор видит проект как инструмент роста бизнеса. Бухгалтер видит его как угрозу привычному порядку. Программист видит его как набор технических задач. Пользователь видит его как лишнюю работу. Задача аналитика — понимать картину мира каждого участника и работать с каждым на его языке.
Теория
Карта участников проекта
В типичном проекте внедрения 1С есть шесть групп участников:
1. Заказчик
2. Ключевые пользователи
3. Конечные пользователи
4. Руководитель проекта
5. Аналитик
6. Программист
Вот как выглядит место аналитика среди участников проекта:
Заказчик
↓
Аналитик
↓
→
Программист
→
Руководитель проекта
→
Ключевые пользователи
→
Конечные пользователи
Разберём каждого подробно.
Участник №1. Заказчик
Кто это:
Собственник бизнеса или топ-менеджер, который принял решение о внедрении системы и выделил бюджет. В группе компаний «БизнесПлюс» — это Андрей Викторович Белов, генеральный директор холдинга.
Чего хочет:
●
чтобы система решила бизнес-задачу
●
чтобы проект уложился в бюджет и сроки
●
чтобы после внедрения бизнес работал лучше
Чего боится:
●
потратить деньги и не получить результат
●
остановки бизнеса в процессе внедрения
●
бесконечных доработок и переносов сроков
Как с ним работает аналитик:
Заказчик — источник стратегических целей. Аналитик встречается с ним в начале проекта, чтобы понять: зачем вообще нужна система, что должно измениться, как будет выглядеть успех. Заказчик формулирует цели, а не технические требования. Его слова «хочу видеть прибыль по каждому магазину» — это цель. Задача аналитика — превратить эту цель в конкретные требования к системе.
Типичная фраза заказчика: «Мне нужно понимать, где мы зарабатываем, а где теряем деньги».
Участник №2. Ключевой пользователь
Кто это:
Сотрудник компании, который хорошо знает свой бизнес-процесс и будет главным представителем своего подразделения в проекте. Это не просто пользователь системы — это эксперт по своему участку работы. В «БизнесПлюс»: Елена Соколова (главный бухгалтер), Алексей Морозов (руководитель склада «ТрансЛог»), Ирина Павлова (старший кассир сети «Стиль»).
Чего хочет:
●
чтобы система работала так, как удобно его подразделению
●
чтобы его учли и услышали
●
чтобы внедрение не сломало то, что уже работает
Чего боится:
●
что система будет неудобной
●
что придётся переучиваться
●
что его игнорируют при принятии решений
Как с ним работает аналитик:
Ключевой пользователь — это главный источник требований. Именно с ним аналитик проводит большинство интервью. Он знает детали процесса: исключения, особые случаи, неочевидные правила. Правило: ключевого пользователя нужно уважать. Он эксперт в своём деле. Аналитик не учит его работать — аналитик учится у него понимать процесс.
Типичная фраза: «У нас это всегда делалось вот так, и менять не нужно».
Участник №3. Конечный пользователь
Кто это:
Рядовой сотрудник, который будет работать в системе каждый день. Кассир, оператор склада, менеджер по продажам.
Чего хочет:
●
чтобы система была простой и понятной
●
чтобы не нужно было делать лишних шагов
●
чтобы система не тормозила работу
Чего боится:
●
что система будет сложной
●
что он сделает ошибку и его накажут
●
что его старые привычки больше не работают
Как с ним работает аналитик:
Аналитик учитывает интересы конечных пользователей при формулировке требований. Если система неудобна для кассира — она не будет работать правильно, сколько бы правильной она ни была технически.
Участник №4. Руководитель проекта
Кто это:
Человек, который управляет проектом со стороны исполнителя (компании-внедренца). Отвечает за сроки, бюджет, команду и результат.
Чего хочет:
●
чтобы проект был сдан в срок
●
чтобы не было неожиданностей
●
чтобы команда работала слаженно
Чего боится:
●
срывов сроков
●
скрытых проблем, о которых узнают в последний момент
Как с ним работает аналитик:
Руководитель проекта — непосредственный руководитель аналитика на проекте. Аналитик регулярно отчитывается ему о статусе: что выяснено, что зафиксировано, какие риски обнаружены.
Участник №5. Аналитик
Кто это:
Ты. Специалист, который стоит на стыке между бизнесом и техническими специалистами. Единственный, кто понимает обе стороны.
Чего хочет:
●
выявлять требования
●
описывать бизнес-процессы
●
формулировать постановки задач
●
контролировать соответствие результата ожиданиям
Чего боится:
●
сделать не то, что на самом деле нужно бизнесу
●
пропустить конфликт интересов между участниками
●
потерять доверие из-за размытой постановки задачи
Как он работает с остальными участниками:
Аналитик — единственный участник проекта, чья основная задача — понимать потребности бизнеса и переводить их в понятные технической команде требования.
Участник №6. Программист
Кто это:
Технический специалист, который реализует требования в системе 1С.
Чего хочет:
●
получить чёткое и понятное техническое задание
●
не получать противоречивых требований
●
не переделывать сделанное по три раза
Чего боится:
●
размытых формулировок («сделай красиво»)
●
постоянно меняющихся требований
●
что заказчик скажет «не то» после сдачи
Как с ним работает аналитик:
Программист — главный получатель результата работы аналитика. Если аналитик написал постановку задачи плохо — программист либо сделает не то, либо придёт с десятком вопросов. Хорошая постановка задачи — это уважение к программисту.
Коротко все шесть участников — для повторения перед практикой или собеседованием:
Участник
Что хочет
Чего боится
Что получает от аналитика
Заказчик
Чтобы система решила бизнес-задачу в срок и бюджет
Потратить деньги и не получить результат
Цели, переведённые в конкретные требования к системе
Ключевой пользователь
Чтобы систему удобно было использовать в его подразделении
Что его не услышат при принятии решений
Уважение к его экспертизе и учёт деталей процесса
Конечный пользователь
Простую и понятную систему без лишних шагов
Что он ошибётся и его накажут
Требования, учитывающие удобство ежедневной работы
Руководитель проекта
Сдать проект в срок без сюрпризов
Скрытых проблем, о которых узнают в последний момент
Регулярные отчёты о статусе и рисках
Аналитик
Выявить настоящие требования и проконтролировать результат
Сделать не то, что на самом деле нужно бизнесу
—
Программист
Чёткое техническое задание без противоречий
Размытых формулировок и постоянных переделок
Постановку задачи, после которой не остаётся вопросов
Конфликты между участниками
Понимать, где возникают противоречия — важная часть работы аналитика.
Конфликт №1. Заказчик vs Ключевой пользователь
Заказчик хочет: «Сократить затраты на склад». Ключевой пользователь (завскладом) слышит: «Меня хотят уволить». Аналитик должен это увидеть и помочь перевести цели заказчика в язык, понятный пользователю: не «сократить людей», а «убрать ручную работу, которая отнимает время у самого завсклада». На практике это может звучать так: аналитик отдельно проговаривает с завскладом, что именно изменится в его работе, и фиксирует его опасения как отдельный пункт для обсуждения с заказчиком — вместо того чтобы просто передать цель дальше как есть.
Конфликт №2. Ключевые пользователи между собой
Бухгалтер: «Документы проводятся только после проверки». Кладовщик: «Документы проводятся сразу, без задержек». Оба правы со своей точки зрения. Аналитик фиксирует конфликт и выносит его на решение руководителю проекта или заказчику. Он не решает такие конфликты самостоятельно.
Конфликт №3. Бизнес vs Программист
Бизнес хочет: «Всё и сразу». Программист говорит: «На это нужно три месяца». Аналитик помогает расставить приоритеты: что нужно сделать в первую очередь, а что можно отложить.
Как выявленный конфликт обычно фиксируется, прежде чем его передать на решение:
Протокол выявленного конфликта
Конфликт: Бухгалтер требует контроль перед проведением документов. Кассир требует максимальную скорость обслуживания.
Решение аналитика: [v] Зафиксировать конфликт. [v] Не принимать решение самостоятельно. [v] Передать вопрос заказчику или руководителю проекта.
Пример из жизни
Представь, что ты строишь дом.
Роль
Кто в аналогии
Заказчик
хозяин дома. Говорит: «Хочу большой, светлый, с гаражом».
Ключевой пользователь
жена хозяина. Знает, как должна быть устроена кухня, где нужны розетки, как расположить детские комнаты. Без неё дом будет красивым снаружи, но неудобным внутри.
Конечный пользователь
дети. Им важно, чтобы была площадка во дворе и своя комната.
Руководитель проекта
прораб. Управляет стройкой, следит за сроками.
Аналитик
архитектор. Слушает всех, переводит пожелания в чертёж.
Программист
строитель. Работает по чертежу.
Если архитектор плохо выслушал жену хозяина — кухня будет неудобной. Если он плохо объяснил строителю — стены встанут не там.
Пример из 1С
Проект внедрения 1С:Управление торговлей в сети «Стиль» из группы «БизнесПлюс».
Андрей Белов (Заказчик): «Хочу видеть прибыль по каждому магазину онлайн»
Елена Соколова (Бухгалтер): «Документы нужно проверять перед проведением, иначе будут ошибки в учёте»
Ирина Павлова (Кассир): «Кассиры не могут ждать подтверждения бухгалтера — очередь стоит»
Кассир Маша (Конечный польз.): «Главное, чтобы чек печатался быстро и не нужно было лишних кликов»
Программист Дмитрий: «Дайте мне чёткое ТЗ — тогда сделаю за неделю. Без ТЗ — буду переделывать месяц»
Видишь конфликт? Бухгалтер хочет контроль. Кассир хочет скорость. Оба правы. Аналитик фиксирует этот конфликт в протоколе встречи и выносит на решение заказчика. Самостоятельно он его не решает — это не его полномочия.
Типичные ошибки новичка
Ошибка №1. «Главный — тот, кто громче говорит»
НЕВЕРНО: Ориентироваться на самого активного участника и выполнять только его требования.
ВЕРНО: Каждый участник важен в своей роли. Директор определяет цели. Бухгалтер знает детали учёта. Кассир знает реальную работу у кассы. Игнорировать любого — значит получить неполную картину.
Ошибка №2. «Я сам решу конфликт между участниками»
НЕВЕРНО: Видя противоречие между бухгалтером и кладовщиком, принять решение самостоятельно: «Ну, наверное, лучше так».
ВЕРНО: Аналитик фиксирует конфликт и эскалирует его — передаёт на уровень выше. Эскалация — это передача вопроса на уровень выше для принятия решения. Самостоятельно решать противоречия между подразделениями — брать на себя чужую ответственность.
Ошибка №3. «Пользователи мешают проекту»
НЕВЕРНО: Воспринимать сопротивление пользователей как помеху: «Они не хотят меняться, тормозят проект».
ВЕРНО: Сопротивление пользователей — это сигнал. Значит, что-то не учтено, есть невыявленное требование. Опытный аналитик воспринимает сопротивление как источник информации.
Практический кейс
Ситуация
Ты — Junior-аналитик на проекте внедрения 1С в медицинском центре «МедЛайн». Руководитель проекта попросил тебя провести первую встречу с представителями заказчика и выяснить требования к модулю записи пациентов. На встречу пришли: главный врач Сергей Николаевич — говорит мало, но смотрит строго; старший администратор Наталья — говорит много, очень активна; IT-специалист центра Павел — говорит только про технические ограничения. Наталья за 40 минут рассказала всё, что хочет. Главный врач сказал две фразы. Павел сказал: «У нас старый сервер, учтите».
Чьи слова являются требованиями? Как распределить роли участников?
Главный врач — Заказчик или ключевой пользователь высокого уровня. Его две фразы могут быть важнее 40 минут Натальи. После встречи нужно договориться об отдельном разговоре с ним.
Наталья — Ключевой пользователь. Ценный источник требований. Но её пожелания нужно проверять: всё ли действительно нужно, а что — просто привычка?
Павел — Технический специалист на стороне заказчика. Его слова про сервер — ограничение, которое нужно зафиксировать и передать программисту.
Все трое важны. Никого нельзя игнорировать.
Практические упражнения
1. Упражнение 1
Возьми любую компанию, которую ты знаешь. Составь список участников, которые были бы задействованы при внедрении 1С. Укажи роль каждого.
2. Упражнение 2
Опиши конфликт интересов между двумя участниками проекта в компании «ТрансЛог» (логистика). Кто мог бы конфликтовать и из-за чего? Как аналитик должен на это реагировать?
3. Упражнение 3
Заказчик говорит: «Моя бухгалтер знает всё — общайтесь только с ней, меня не беспокойте». Что ты сделаешь? Напиши свои действия по шагам.
Ориентир для самопроверки
●
В упражнении 1 — у каждого участника в твоём списке названа конкретная роль (заказчик/ключевой/конечный пользователь и т.д.), а не просто «сотрудники компании»?
●
В упражнении 2 — виден ли в твоём описании интерес каждой стороны, а не только сам факт разногласия?
●
В упражнении 3 — есть ли в твоих шагах явное «не отказываюсь от контакта с заказчиком полностью», а не только «буду общаться с бухгалтером»?
Контрольные вопросы
1. Назови шесть групп участников проекта внедрения 1С.
2. Чем ключевой пользователь отличается от конечного пользователя?
3. Чего хочет заказчик и чего боится?
4. Почему программист хочет чёткое техническое задание?
5. Что такое эскалация и когда аналитик её применяет?
6. Почему сопротивление пользователей — это не помеха, а сигнал?
7. Что делает аналитик, когда два участника предъявляют противоречивые требования?
Что спрашивают на собеседовании
Вопрос: Кто такой ключевой пользователь и чем он отличается от конечного пользователя?
Ответ Junior: Ключевой пользователь — это тот, кто хорошо знает свою работу и участвует в проекте. А конечный пользователь — это обычный сотрудник, который просто работает в системе.
Ответ опытного аналитика: Ключевой пользователь — эксперт по бизнес-процессу своего подразделения. Он участвует в проекте активно: ходит на встречи, согласует требования, проверяет результат. Именно он — главный источник требований для аналитика, потому что знает не только как должно быть, но и все исключения и неочевидные правила. Конечный пользователь работает в системе, но в проекте почти не участвует. Путать их опасно: если брать требования только от конечных пользователей — получишь список бытовых пожеланий без понимания бизнес-логики. Если игнорировать конечных — получишь систему, которой никто не хочет пользоваться.
Вопрос: Что делать, если требования двух участников проекта противоречат друг другу?
Ответ Junior: Нужно попробовать найти компромисс. Поговорить с обоими и объяснить, что лучше для проекта.
Ответ опытного аналитика: Прежде всего — зафиксировать конфликт письменно. Описать: кто, что хочет, в чём противоречие, какие последствия у каждого варианта. Затем вынести на уровень, где есть полномочия принять решение — руководителю проекта или заказчику. Моя задача как аналитика — не решить конфликт, а сделать его видимым и управляемым. Нерешённый конфликт требований — это мина замедленного действия: он взорвётся на этапе тестирования или сдачи.
Вопрос: Как вы будете работать с заказчиком, который говорит «у меня нет времени на встречи»?
Ответ Junior: Постараюсь договориться на короткую встречу в удобное для него время.
Ответ опытного аналитика: Предложу самый компактный формат — например, 15-минутный звонок вместо часовой встречи, и заранее пришлю список из 2-3 ключевых вопросов, чтобы заказчик видел, что его время ценят. Если и это невозможно — предложу поговорить с его заместителем или ключевым пользователем, но обязательно зафиксирую, что решение по стратегическим вопросам всё равно нужно будет согласовать с заказчиком лично, пусть даже позже. Полностью отказаться от контакта с заказчиком нельзя — рискую не понять реальную цель проекта.
Итоговые выводы
●
В проекте шесть групп участников: заказчик, ключевые пользователи, конечные пользователи, руководитель проекта, аналитик, программист.
●
У каждого участника своя картина мира, свои цели и свои страхи.
●
Аналитик работает с каждым участником на его языке.
●
Конфликты между участниками — норма. Аналитик их фиксирует и эскалирует, но не решает самостоятельно.
●
Сопротивление пользователей — сигнал о невыявленном требовании, а не помеха.
●
Ключевой пользователь — главный источник требований аналитика.
Понимать людей — такой же профессиональный навык аналитика, как и понимать систему.
От автора
Самая частая ошибка, которую я видела у себя и у других новичков — слушать не самого важного участника, а самого активного. Кто громче и увереннее говорит на встрече, тот и кажется главным источником истины. На деле директор, который сказал всего два слова, часто важнее сотрудника, который говорил сорок минут. Научиться взвешивать голоса, а не просто их слышать — то, что приходит только с практикой, но начать тренировать это можно с первой же встречи.
Самопроверка
Я знаю участников проекта
[ ] Я могу назвать все шесть групп участников без подсказки.
[ ] Я понимаю, чем ключевой пользователь отличается от конечного.
[ ] Я могу объяснить, почему программист — получатель результата работы аналитика.
Я понимаю интересы участников
[ ] Я понимаю, чего хочет заказчик и чего боится.
[ ] Я понимаю, почему ключевой пользователь может сопротивляться изменениям.
[ ] Я понимаю, что нужно программисту для хорошей работы.
Я понимаю конфликты
[ ] Я знаю, что такое эскалация и когда её применять.
[ ] Я понимаю, почему аналитик не решает конфликты самостоятельно.
Я готов к собеседованию
[ ] Я могу ответить на вопрос про противоречивые требования так, как ответил бы опытный аналитик.
[ ] Я могу объяснить разницу между ключевым и конечным пользователем развёрнуто, а не одной фразой.
[x] Все галочки стоят — Можно переходить к Главе 3
[ ] Есть непроставленные галочки — Вернись к соответствующему разделу. Не торопись — лучше понять сейчас, чем запутаться потом.
Глава 3
Бизнес-процесс — что это и зачем аналитику его понимать
Часть II. Бизнес-процессы
Зачем читать эту главу
Аналитик постоянно слышит слово «бизнес-процесс». На встречах, в документах, на собеседованиях. Но большинство новичков понимают его размыто: «ну, это как что-то делается в компании». Этого недостаточно.
Если аналитик не умеет видеть бизнес-процесс — он не может правильно собрать требования. Он будет фиксировать отдельные пожелания, не понимая, как они связаны между собой. В результате система автоматизирует хаос вместо того, чтобы его устранить.
После этой главы ты будешь:
●
понимать, что такое бизнес-процесс и из чего он состоит
●
уметь описывать процесс шаг за шагом
●
видеть, где процесс ломается
●
понимать разницу между процессом «как есть» и «как должно быть»
●
уметь задавать правильные вопросы о процессе
Центральная идея главы
Аналитик автоматизирует не кнопки — он автоматизирует процессы.
Прежде чем думать о системе — нужно понять, что происходит в бизнесе. Как движется работа. Где она начинается, где заканчивается, кто что делает и в какой момент. Система — это лишь инструмент. Процесс — это реальность бизнеса.
Теория
Что такое бизнес-процесс
Бизнес-процесс — это последовательность действий, которая превращает входящий запрос в результат, имеющий ценность для бизнеса.
Последовательность действий — процесс всегда состоит из шагов. Один шаг следует за другим. Это не набор случайных действий, а цепочка.
Входящий запрос — у каждого процесса есть триггер — событие, которое его запускает. Клиент позвонил. Пришёл товар. Поступила заявка.
Результат — процесс всегда заканчивается чем-то конкретным. Товар отгружен. Счёт выставлен. Пациент записан.
Ценность для бизнеса — если результат процесса не нужен бизнесу — процесс не нужен.
В виде простой схемы это выглядит так:
Триггер
↓
Последовательность действий
↓
Результат
↓
Получатель результата
Из чего состоит бизнес-процесс
Любой бизнес-процесс имеет пять обязательных элементов. Разберём их сразу на одном сквозном примере — процессе оформления заказа в интернет-магазине «ТехноМаркет» из группы «БизнесПлюс».
Элемент 1. Триггер — событие, которое запускает процесс.
Без триггера процесс не начинается. Триггер всегда внешний — что-то произошло.
Пример: Покупатель нажал кнопку «Оформить заказ» на сайте.
Элемент 2. Шаги — действия, которые выполняются по порядку.
Каждый шаг — это конкретное действие конкретного человека или системы.
Пример: Система проверяет наличие → менеджер подтверждает заказ → склад собирает товар → курьер доставляет → покупатель получает и подписывает накладную.
Элемент 3. Участники — люди и системы, которые выполняют шаги.
У каждого шага есть ответственный. Если ответственного нет — шаг не будет выполнен.
Пример: Покупатель, система сайта, менеджер, кладовщик, курьер.
Элемент 4. Документы и данные — что создаётся и передаётся.
На каждом шаге что-то фиксируется или передаётся дальше.
Пример: Заказ на сайте → подтверждение менеджера → задание на сборку → накладная на доставку → подпись о получении.
Элемент 5. Результат — чем заканчивается процесс.
Результат должен иметь ценность. Если покупатель не получил товар — процесс не завершён, даже если все шаги формально выполнены.
Пример: Покупатель получил товар, деньги зачислены, заказ закрыт в системе.
Именно так аналитик структурирует то, что ему рассказывают на интервью — разбивает хаотичный рассказ на пять чётких элементов.
Тот же процесс «ТехноМаркет», но записанный так, как аналитик фиксирует его у себя — без сложных нотаций, простой таблицей:
Шаг
Кто выполняет
Действие
Результат
1
Система сайта
Проверяет наличие товара
Товар зарезервирован или заказ отклонён
2
Менеджер
Подтверждает заказ
Заказ передан на склад
3
Кладовщик
Собирает товар
Товар готов к отправке
4
Курьер
Доставляет заказ
Товар у покупателя
5
Покупатель
Подписывает накладную
Заказ закрыт в системе
Процесс «как есть» и процесс «как должно быть»
Это один из ключевых инструментов аналитика. Запомни эти два термина — они будут встречаться постоянно.
AS-IS («как есть») — Описание того, как процесс работает прямо сейчас, в реальности. Со всеми недостатками, обходными путями и ручной работой.
TO-BE («как должно быть») — Описание того, как процесс должен работать после внедрения системы.
Важно: нельзя проектировать TO-BE, не понимая AS-IS. Иначе получишь красивую схему, которая не учитывает реальные ограничения бизнеса.
AS-IS
TO-BE
Как работает сейчас
Как должно работать после изменений
Существующие проблемы
Предлагаемое улучшение
Фактический процесс
Целевой процесс
Где процесс ломается
Опытный аналитик смотрит на процесс и сразу ищет точки разрыва — места, где что-то идёт не так.
Точка разрыва
Пример
Ручная работа там, где можно автоматизировать
Менеджер вручную переносит данные из Excel в 1С.
Ожидание
Документ лежит на согласовании три дня, потому что директор в командировке.
Дублирование
Одни и те же данные вводятся в два разных места.
Потеря информации
Устная договорённость нигде не зафиксирована.
Неясная ответственность
Непонятно, кто должен сделать следующий шаг.
Именно в этих точках бизнес теряет деньги и время. Именно здесь система 1С может помочь.
Пример из жизни
Представь, что ты заказываешь пиццу по телефону.
Триггер: Ты позвонил в пиццерию.
Шаги: 1. Оператор принял звонок и записал заказ. 2. Заказ передан на кухню. 3. Повар приготовил пиццу. 4. Курьер забрал заказ. 5. Курьер доставил пиццу. 6. Ты оплатил.
Участники: Ты, оператор, повар, курьер.
Документы: Заказ, чек.
Результат: Ты получил пиццу, пиццерия получила деньги.
А теперь представь: оператор записал заказ на бумажке, которую потерял. Повар не получил заказ. Курьер ждёт. Ты злишься. Это и есть точка разрыва процесса. И именно здесь нужна автоматизация — чтобы заказ не терялся.
Пример из 1С
Процесс продажи товара в розничной сети «Стиль» из группы «БизнесПлюс».
AS-IS — как есть сейчас
Триггер: покупатель выбрал товар и подошёл к кассе. 1. Кассир находит товар в системе вручную — занимает 2 минуты. 2. Кассир проверяет наличие скидки по бумажному прайсу — иногда прайс устаревший. 3. Кассир вводит сумму вручную — бывают ошибки. 4. Покупатель платит. 5. Кассир печатает чек. 6. В конце смены кассир вручную сводит кассу в Excel. Проблемы: медленно, ошибки в скидках, ручной ввод суммы, ручная сводка кассы.
TO-BE — как должно быть
1. Кассир сканирует штрихкод — товар определяется автоматически. 2. Скидка применяется автоматически по актуальным данным системы. 3. Сумма рассчитывается автоматически. 4. Покупатель платит. 5. Система автоматически печатает чек и фиксирует продажу. 6. Кассовый отчёт формируется автоматически в конце смены.
Что изменилось: убрали ручной труд, убрали ошибки, ускорили обслуживание. Вот что такое автоматизация бизнес-процесса. Не «поставить 1С», а убрать конкретные точки разрыва.
Типичные ошибки новичка
Ошибка №1. «Я опишу процесс так, как мне объяснили»
НЕВЕРНО: Записать рассказ ключевого пользователя и считать задачу выполненной.
ВЕРНО: Люди описывают процесс так, как он должен работать по их мнению — не так, как он работает на самом деле. Реальный процесс всегда имеет исключения и обходные пути. Правильный подход: задавать уточняющие вопросы — «А что происходит, если...?», «Бывают ли исключения?»
Ошибка №2. «Автоматизируем всё подряд»
НЕВЕРНО: Видеть ручную работу и сразу думать: «Надо автоматизировать».
ВЕРНО: Не каждый ручной шаг нужно автоматизировать. Иногда ручной контроль — намеренное решение. Аналитик автоматизирует то, что даёт реальную пользу — не всё подряд.
Ошибка №3. «У нас всё нормально, просто нужна система»
НЕВЕРНО: Поверить заказчику, что процессы работают хорошо, и описывать идеальную картину.
ВЕРНО: Почти в каждой компании процессы содержат хаос — дублирование, ручные обходные пути, неформальные договорённости. Люди об этом знают, но стесняются говорить. Задача аналитика — создать безопасную атмосферу, в которой люди честно описывают реальность. Если описать красивый процесс, которого не существует — система будет внедрена на бумаге, но не в жизни.
Практический кейс
Ситуация
Ты — Junior-аналитик. Тебя отправили на интервью к руководителю склада «ТрансЛог» Алексею Морозову. Задача: описать процесс приёмки товара на склад. Алексей говорит: «Когда приходит машина, кладовщик выходит, проверяет накладную, принимает товар, ставит подпись и вносит данные в систему. Всё просто».
Что делать дальше?
Вопросы, которые нужно задать:
●
Что происходит, если количество товара в накладной не совпадает с фактическим?
●
Что делать, если товар повреждён?
The free sample has ended.
