Функциональный разрыв 1с что это
Ключевые бизнес-процессы крупных предприятий — это непрерывно развивающаяся система, и ее развитие порождает массу проблем, когда речь идет об автоматизации. Решать эти проблемы призваны не столько ИТ‑инструменты, сколько люди.
Все гуру в области предпринимательства и менеджмента говорят: «Ищите и усиливайте отличия, специализируйтесь, меняйтесь, развивайтесь», — а после внедрения от ИТ‑директоров мы слышим: «Ничего не трогайте и не меняйте, только тогда всё будет работать». Один мой знакомый управляющий в сердцах так описал чудовищный функциональный разрыв, который возникает в таких проектах: «Они (вендоры) берут свое маленькое квадратное ведро и надевают на нашу большую круглую голову!».
Почему это происходит? На мой взгляд, основная причина в том, что для решения задач автоматизации выбираются инструменты, а не люди. А инструмент не может побороть системную сложность организации, у него нет интеллекта. Это могут сделать только люди, да и то очень немногие.
Системная сложность
Крупные организации — это такие компании, которым повезло: благодаря интуиции и везению их основателей, благодаря многолетней работе их менеджмента на перспективу они добились лидирующего положения. Но для сохранения своего преимущества организация должна постоянно обеспечивать следующее.
1. Превосходство ключевых бизнес-процессов по отрасли — за счет новых технологий, за счет большей специализации, за счет новых маркетинговых идей. Именно этим определяется текущее (статическое) конкурентное преимущество организации: в важном она не такая, как все, и именно поэтому — лидер, именно поэтому эффективнее других!
2. Опережающую модернизацию ключевых бизнес-процессов. Прогресс не стоит на месте: технология, которая несколько лет назад была инновацией, отличительной чертой немногих, сегодня для большинства предприятий — стандарт де-факто. Чтобы не утратить лидирующее положение, необходимо периодически видоизменять ключевые бизнес-процессы. Для организации в целом это выливается в дискретно-непрерывное обновление своей деятельности. Умение совладать с процессом изменений и не потерять устойчивость — вот ее динамическое преимущество перед конкурентами. Попросту говоря, организация должна бежать вперед быстрее других.
Это очень легко сказать, но очень трудно сделать. Основная причина в том, что большая организация является сложной открытой системой. И как любая сложная система, обладает собственной скрытой логикой развития. Управленческие воздействия на такие объекты далеко не всегда приводят к ожидаемым результатам. На моей памяти множество историй, когда попытки что‑то улучшить в организации приводили к кризису, для разрешения которого приходилось вводить антикризисное управление в лице лучших из лучших специалистов. И дело вовсе не в том, что кто‑то «плохо поразмыслил», запуская изменения в компании, а в том, что точный расчет поведения сложных систем до сих пор неподвластен человеческому интеллекту.
Но как бы ни было трудно совладать с системной сложностью предприятия при модернизации бизнес-процессов, это приходится делать. Ибо альтернатива печальна: вначале предприятие потеряет перспективы, а затем — и свое лидирующее положение.
Функциональный разрыв
Теперь пришло время посмотреть на крупное предприятие глазами ИТ‑специалистов, которые отвечают за его автоматизацию. Причем я ограничусь рассмотрением автоматизации ключевых бизнес-процессов, где изменения — правило, а не исключение. И буду это делать в позитивном залоге, то есть исходить из следующих предположений:
- ИТ-директор обслуживает интересы бизнеса (а не вендоров, что, к сожалению, тоже бывает). В первую очередь важно, что ИТ-директор поддерживает (а не сдерживает!) необходимый темп изменения бизнес-процессов;
- существует концептуальный проект информационной системы предприятия, который периодически пересматривается. Это своего рода генеральный план развития информационной системы с декомпозицией на модули первого уровня от состояния «как есть» к состоянию «как будет»;
- пришло время кардинально изменить один из ключевых бизнес-процессов. Для этого требуется замена нескольких имеющихся модулей информационной системы на один новый, который, как предполагается, будет отвечать за реализацию модернизированного бизнес-процесса.
Итак, мы стоим у начала проекта. На рис. 1 схематично изображено соотношение функционала бизнес-процесса и модуля информационной системы. В многомерном пространстве требований точкой «цель» обозначен проект функционала модуля так, как он понимается на момент старта проекта. Точкой «прототип» обозначен функционал существующего прототипа — модуля или платформы развития от вендора либо собственной разработки ИТ‑служб предприятия (строго говоря, функциональность надо рисовать как перекрывающиеся области, но для дальнейшего изложения это несущественно).
Тут мы сталкиваемся с функциональным разрывом — разницей между «целевым» функционалом, который нужен бизнесу, и функционалом «прототипа», который реализован в модуле (разрыв иллюстрируется расстоянием между точками).
Отмечу три важных факта. Во-первых, функционал цели размыт — это лишь текущее представление о проектируемом бизнес-процессе, и оно не может быть точным (на схеме точка «цель» размыта). Во-вторых, функционал «цели» меняется во времени за счет внешних воздействий. В-третьих, по мере погружения проектируемого бизнес-процесса в жизнь нас ждут непредсказуемые заранее реакции предприятия на попытки его изменить. Как я уже говорил выше, это объективная вещь, связанная с системной сложностью предприятия: невозможно точно предсказать, как поведет себя система при воздействии на ее части. В результате представление о функционале цели будет существенно изменяться во времени (на рисунке это обозначено черной стрелкой).
Далее начинается длительный итеративный процесс ликвидации функционального разрыва. Это весьма непросто даже в том случае, если «цель» зафиксирована. И это очень сложный процесс, если понимание цели изменяется во времени.
В случае результативного внедрения функциональный разрыв сокращается до минимума (на рис. 1 и 2 —«результативное внедрение»). Более того, возникает положительная обратная связь. Чем ближе функционал «прототипа» к реальным бизнес-процессам, тем активнее эти бизнес-процессы развиваются. Что позволяет предприятию усиливать свою позицию быстрее конкурентов. Подробнее с результативным внедрением разберемся в следующем разделе.
В остальных случаях функциональный разрыв остается значительным и перекладывается на плечи бизнес-подразделений (на рис. 1 и 2 — «слабое внедрение»). В лучшем варианте это приведет к появлению «наколеночной» автоматизации внутри подразделений, которая будет этот разрыв сокращать: Excel, Access и похожие инструменты в умелых руках инициативных бизнес-пользователей. В худшем — организация надолго утратит возможность изменения ключевого бизнес-процесса, что является серьезной угрозой для существования всей компании в целом.
Результативное внедрение
В современном ИТ‑сообществе понятие результативного внедрения трактуется очень вольно. Вот далеко не полный перечень достижений, каждое из которых может именоваться «результативным внедрением» некоторого функционального модуля:
- куплены лицензии. На самом деле это формальное внедрение;
- модуль функционирует на тестовом стенде — еще один случай формального внедрения;
- модуль числится в промышленной эксплуатации, но реально используется «старый» модуль. Я встречал забавные случаи, когда новая система «подымается» только на время приезда инспекции из материнской компании. Это тоже формальное внедрение;
- часть модуля находится в промышленной эксплуатации, однако «старый» модуль по‑прежнему развивается для поддержания необходимой бизнесу функциональности. Именно посредством «старого» модуля достигается уменьшение функционального разрыва. Это пример слабого внедрения.
Чтобы избежать терминологической путаницы, под результативным внедрением функционального модуля информационной системы я буду подразумевать одновременное выполнение следующих условий:
- модуль находится в промышленной эксплуатации — количество усилий, которые тратятся на исправление ошибок, многократно меньше количества усилий, которые тратятся на развитие;
- большая часть старых модулей (подсистем), которые реализовывали схожую функциональность до внедрения нового модуля, выведена из эксплуатации;
- подавляющий объем новых требований бизнеса реализуется вовремя путем развития функциональности нового модуля (вокруг нового модуля не образуется слой «наколеночных» решений), т.е. не возникает существенного функционального разрыва.
ИТ-директорам, которым удается поддержать именно такой сценарий развития информационной системы предприятия, предлагаю (безо всякой иронии) ставить памятник при жизни. И этот памятник должен символизировать бессмертное изречение: «Надо очень быстро бежать вперед, чтобы оставаться на месте». А для того, чтобы чего‑то достичь, нужно бежать ещё быстрей…
Поведенческие индикаторы прогрессора
Прогрессоры
Итак, мы вплотную приблизились к ответу на вопрос: что надо сделать, чтобы внедрение было результативным? Для начала отвечу так. Надо обуздать системную сложность, причем дважды: во‑первых, живой системы, то есть организации, а во‑вторых, внедряемого прототипа, который сам по себе является сложной информационной системой. Совет в духе «хочешь быть здоровым — будь им».
А вот чтобы сделать это с высокой степенью гарантии, вам придется найти практикующих системных аналитиков с очень высоким уровнем компетенции, которых я далее буду именовать «прогрессорами» — как людей, способных к реализации мощных прорывных проектов.
Во-первых, прогрессор должен обладать великолепным концептуальным (системным) мышлением. Он в состоянии распознавать внутреннее устройство системы и строить адекватные модели. Он умеет упрощать сложность — собирает идеи, вопросы, наблюдения в единое представление. Он умеет задавать «прорезающие» вопросы в сложной ситуации.
Во-вторых, прогрессор должен непрерывно заботиться о качестве в широком смысле этого слова. Он нацелен на увеличение порядка в существующей системе (бизнес-процессе). Он непрерывно выявляет слабые стороны и изъяны в данных и ищет информацию для поддержания в них порядка.
В-третьих, прогрессор чувствует себя в изменяющейся ситуации как рыба в воде. Он сохраняет уверенность в условиях неопределенности. Он признает ограниченность своих знаний, умений и навыков. Он впитывает в себя всё новое, как губка.
Он неплохой коммуникатор — по крайней мере он заинтересован в результативности взаимодействия и умеет не вызывать раздражения у собеседников, представляя свою точку зрения.
В довершение всего прогрессор результативен. Он способен достигать поставленную цель несмотря на препятствия, причем стремится получить наилучший результат из возможных.
Как выбрать прогрессора
«Дай‑ка, дай‑ка мне ответ, ты прогрессор или нет?». Как отыскать нужного человека? Надо найти человека, который в условиях высокой динамики требований вел результативный проект, похожий на тот, который предстоит выполнить вам:
1) схожего масштаба с нужной вам тематикой (отлично);
2) схожего масштаба с другой тематикой (хорошо);
3) меньшего масштаба (удовлетворительно).
Второй вариант, как это ни странно, не сильно отличается от первого. Объясняется это тем, что компетенции практического системного анализа очень слабо привязаны к предметной области. Основные риски здесь будут в том, что инструмент, которым владеет прогрессор, не подойдет для вашего проекта.
Третий вариант опасен по двум причинам: во‑первых, увеличение масштаба системы может потребовать от кандидата принципиально новых умений, а они пока не доказаны; во‑вторых, ограничения по инструменту тоже могут оказаться неприемлемыми.
Проверить достижения кандидата, а также убедиться, что это именно его достижения, можно только одним способом: нанести несколько визитов в те организации, в которых он успел потрудиться. И в каждой несколько раз без посредников поговорить с очевидцами проекта (именно с очевидцами, а не с теми, кто о нём «слышал»). Идеально, чтобы среди них был сотрудник ИТ‑службы, отвечавший за внедрение проекта со стороны компании. Неплохо подойдет и один из ключевых бизнес‑пользователей.
Спрашивайте всё, что вам интересно, но не забывайте своей цели: вам нужно понять, что именно ваш кандидат создал модель бизнес-процесса, которая результативно внедрена, невзирая на высокую динамику требований в процессе внедрения (еще раз посмотрите на критерии результативного внедрения!). И на всякий случай проверьте, что он подходит под описанный мной «портрет компетенций». Если вы обнаружите сильное несоответствие, то велика вероятность, что вел проект кто‑то другой. Попробуйте найти именно его… И наконец, получите весомые гарантии того, что выбранный вами кандидат (именно он!) и будет вести ваш проект до окончания внедрения.
После результативного внедрения
Начав работать с прогрессором, вы должны понимать, что после результативного внедрения он обязательно будет искать себе другой проект. Поэтому заранее позаботьтесь о защите своих инвестиций.
Во-первых, добейтесь, чтобы люди, которые будут отвечать за развитие проекта после внедрения, появились в проекте как можно раньше (на рис. 2 «инженер»). Прогрессор почти наверняка даст вам трезвую оценку, есть ли в проектной команде такие люди. Только продолжительная совместная работа с прогрессором в ходе внедрения позволит «инженеру» в будущем отвечать за самостоятельное развитие модуля. Это единственный вариант трансляции знаний, который позволит вести устойчивое развитие модуля в соответствии с заложенными моделями, архитектурой и дизайном.
Во-вторых, найдите прогрессору следующий проект в своей организации, если это возможно. Каждый проверенный прогрессор — это тот актив, который помогает вам развивать бизнес. Или хотя бы сохраните партнерские отношения с ним. Он вам очень пригодится, если автоматизированный в модуле бизнес-процесс придется еще раз кардинально изменять.
Один в поле не воин
За рамками статьи осталось много факторов, необходимых для результативного внедрения:
- объективная необходимость проекта для организации;
- внятное управление проектом со стороны заказчика;
- слаженная проектная команда, которая работает с прогрессором;
- достойный уровень инструментального оснащения (т. е. «прототипа»);
- гибкие технологии проектного управления…
Но будьте уверены: если вы действительно нашли прогрессора, если он согласился работать вместе с вами над проектом, если через полгода совместной работы вы еще вместе, то вероятность успеха проекта очень высока.
Владимир Рахтеенко
Генеральный директор компании «Заказные ИнформСистемы» (CustIS)
Выдержка из публикации профессора Н.Е. Жуковского «О парении птиц». 1891 г.
Сегодня же необходимо создать программную модель самолёта, поместить её в виртуальную среду, подать возмущающие воздействия и получить результат в виде сильных и слабых сторон исследования. Нет, это не так просто, но это стало технически возможно. Более того, существуют инженерные авиасимуляторы, например, «X Plane», которые учитывают всю физику происходящего с самолётом и рядом с ним, и, даже если задаться вопросом что произойдёт, когда выпустят интерцептор на крейсерской скорости, то можно получить достаточно точный ответ.
На выходе функциональное моделирование (ФМ) даёт приблизительный результат (точный даст — опытная эксплуатация):
- работает ли концептуальная модель?
- соответствует ли она поставленным техническим- или бизнес-требованиям?
- какие ограничения и границы модели?
- уязвимости, ограничения, экономика проекта и др.
Должен ли владелец бизнеса ответить на те же вопросы при запуске новой системы 1С:Предприятие (1С ERP, КА, УТ и др.) да и всего остального ? Однозначно. Функциональное моделирование как раз для этого и предназначено.
Предлагаю оглавление по документу ФМ:
- Описание бизнес-процессов предприятия (As is/To be).
- Выбор решений программного и аппаратного обеспечений.
- Насколько соответствует типовое решение техническим требованиям и бизнесу?
- Какая допустимая нагрузка на систему / подсистемы?
- Какие условия информационной безопасности?
- Обзор текущей инфраструктуры.
- Какие функциональные разрывы между системой и бизнес-процессами и способы их устранения?
Модель «To be» описывается всегда.
Модель «As is» описывается в случаях работающих (управляемых и осознанных) процессов предприятия, составления стратегии плавной реорганизации, для определения критериев эффективности новой архитектуры.
Вернёмся к математике, к формуле нормального распределения, график которого имеет следующий вид:
В общих словах, большие отклонения имеют малую вероятность (незаштрихованные области) и чем больше отклонение, тем реже оно встречается. Разработчик массового программного обеспечения должен укладывать функционал системы в среднеквадратическое отклонение (заштрихованную область) — в то, что с наибольшей вероятностью будет использоваться на большинстве предприятий.
В ФМ требуется определить попадание бизнес-процессов в функциональность системы. Если количество редких бизнес-процессов велико, то требуется выбирать иное программное обеспечение (комплекс программ) или значительно дорабатывать существующее. Требуется компетенция аналитика, то есть знание продукта и отсутствие неловкости в вопросах «почему? и «зачем?».
Ниже представлен слайд отчёта фирмы 1С по программному продукту 1С ERP, который резюмирует, что «89% функционала внедряется без доработок или с небольшими доработками».
Возражения пользователей на тему «1С не делает самый необходимый важный функционал» остаются лишь эмоциями.
Фирма 1С разрабатывает и предоставляет внедренцам комплекс программ «1С:Корпоративный инструментальный пакет 8» для повышения успеха проектов, в том числе на этапе функционального моделирования.
Основные задачи «1С:Корпоративного инструментального пакета 8»:
- автоматизированное проведение многопользовательских нагрузок без участия пользователей;
- оценка применимости и масштабируемости системы в соответствии технических требований;
- выбор аппаратного(серверного) и программного обеспечения;
- расчёт показателей производительности системы во время ее нагрузочных испытаний или рабочей эксплуатации;
- информация по динамике производительности системы;
- поиск и «узких мест» и оптимизация кода системы;
- автоматизированное функциональное тестирование конфигураций.
Это больше чем необходимо на ФМ, но крайне важно на средних и крупных проектах (внедрения по технологиям ТБР и ТКВ). Для внедрения ТСВ (Технология стандартного внедрения) допускается не делать нагрузочное тестирование.
Результатом функционального моделирования должен стать:
- одноимённый документ, в котором описаны бизнес-процессы, поведения системы, результаты тестирования и требуемые функциональные доработки,
- база(ы) данных.
Несколько моделей предназначены для варианта нескольких кандидатов типовых/отраслевых решений Для принятия правильного решения требуется предоставить сравнительную характеристику, например SWOT-анализ.
Рабочая папка наполняется большим количеством файлов, которые созданы в работе следующим программным обеспечением:
- Предполагаемое типовое/отраслевое решение;
- MS Word для описания результатов;
- MS Visio, Coral Draw для описания бизнес-процессов, блок-схем, граф-схем и т.п.;
- MS Paint, Joxi, Screenshoter Mail для снимков экрана;
- MS Project для планирования работ, затрат, трудозатрат;
- MS Excel для описания структуры отчётов, печатных форм.
Пример документа «Функциональное моделирование» упрощённой версии можно получить по email «doc@ingraf.su» с темой «Лайт».
Почему это происходит? На мой взгляд, основная причина в том, что для решения задач автоматизации выбираются инструменты, а не люди. А инструмент не может побороть системную сложность организации, у него нет интеллекта. Это могут сделать только люди, да и то очень немногие.
Системная сложность
Крупные организации — это такие компании, которым повезло: благодаря интуиции и везению их основателей, благодаря многолетней работе их менеджмента на перспективу они добились лидирующего положения. Но для сохранения своего преимущества организация должна постоянно обеспечивать следующее.
1. Превосходство ключевых бизнес-процессов по отрасли — за счет новых технологий, за счет большей специализации, за счет новых маркетинговых идей. Именно этим определяется текущее (статическое) конкурентное преимущество организации: в важном она не такая, как все, и именно поэтому — лидер, именно поэтому эффективнее других! 2. Опережающую модернизацию ключевых бизнес-процессов. Прогресс не стоит на месте: технология, которая несколько лет назад была инновацией, отличительной чертой немногих, сегодня для большинства предприятий — стандарт де-факто. Чтобы не утратить лидирующее положение, необходимо периодически видоизменять ключевые бизнес-процессы. Для организации в целом это выливается в дискретно-непрерывное обновление своей деятельности. Умение совладать с процессом изменений и не потерять устойчивость — вот ее динамическое преимущество перед конкурентами. Попросту говоря, организация должна бежать вперед быстрее других.
Это очень легко сказать, но очень трудно сделать. Основная причина в том, что большая организация является сложной открытой системой. И как любая сложная система, обладает собственной скрытой логикой развития. Управленческие воздействия на такие объекты далеко не всегда приводят к ожидаемым результатам. На моей памяти множество историй, когда попытки что-то улучшить в организации приводили к кризису, для разрешения которого приходилось вводить антикризисное управление в лице лучших из лучших специалистов. И дело вовсе не в том, что кто-то «плохо поразмыслил», запуская изменения в компании, а в том, что точный расчет поведения сложных систем до сих пор неподвластен человеческому интеллекту.
Но как бы ни было трудно совладать с системной сложностью предприятия при модернизации бизнес-процессов, это приходится делать. Ибо альтернатива печальна: вначале предприятие потеряет перспективы, а затем — и свое лидирующее положение.
Функциональный разрыв
-
ИТ-директор обслуживает интересы бизнеса (а не вендоров, что, к сожалению, тоже бывает). В первую очередь важно, что ИТ-директор поддерживает (а не сдерживает!) необходимый темп изменения бизнес-процессов;
Итак, мы стоим у начала проекта. На рис. 1 схематично изображено соотношение функционала бизнес-процесса и модуля информационной системы. В многомерном пространстве требований точкой «цель» обозначен проект функционала модуля так, как он понимается на момент старта проекта. Точкой «прототип» обозначен функционал существующего прототипа — модуля или платформы развития от вендора либо собственной разработки ИТ-служб предприятия (строго говоря, функциональность надо рисовать как перекрывающиеся области, но для дальнейшего изложения это несущественно).
Рис. 1. ИТ-проект в многомерном пространстве требований
Тут мы сталкиваемся с функциональным разрывом — разницей между «целевым» функционалом, который нужен бизнесу, и функционалом «прототипа», который реализован в модуле (разрыв иллюстрируется расстоянием между точками).
Отмечу три важных факта. Во-первых, функционал цели размыт — это лишь текущее представление о проектируемом бизнес-процессе, и оно не может быть точным (на схеме точка «цель» размыта). Во-вторых, функционал «цели» меняется во времени за счет внешних воздействий. В-третьих, по мере погружения проектируемого бизнес-процесса в жизнь нас ждут непредсказуемые заранее реакции предприятия на попытки его изменить. Как я уже говорил выше, это объективная вещь, связанная с системной сложностью предприятия: невозможно точно предсказать, как поведет себя система при воздействии на ее части. В результате представление о функционале цели будет существенно изменяться во времени (на рисунке это обозначено черной стрелкой).
Далее начинается длительный итеративный процесс ликвидации функционального разрыва. Это весьма непросто даже в том случае, если «цель» зафиксирована. И это очень сложный процесс, если понимание цели изменяется во времени.
В случае результативного внедрения функциональный разрыв сокращается до минимума (на рис. 1 и 2 —«результативное внедрение»). Более того, возникает положительная обратная связь. Чем ближе функционал «прототипа» к реальным бизнес-процессам, тем активнее эти бизнес-процессы развиваются. Что позволяет предприятию усиливать свою позицию быстрее конкурентов. Подробнее с результативным внедрением разберемся в следующем разделе.
В остальных случаях функциональный разрыв остается значительным и перекладывается на плечи бизнес-подразделений (на рис. 1 и 2 — «слабое внедрение»). В лучшем варианте это приведет к появлению «наколеночной» автоматизации внутри подразделений, которая будет этот разрыв сокращать: Excel, Access и похожие инструменты в умелых руках инициативных бизнес-пользователей. В худшем — организация надолго утратит возможность изменения ключевого бизнес-процесса, что является серьезной угрозой для существования всей компании в целом.
Рис. 2. ИТ-проект в многомерном пространстве требований
Результативное внедрение
- куплены лицензии. На самом деле это формальное внедрение;
- модуль функционирует на тестовом стенде — еще один случай формального внедрения;
- модуль числится в промышленной эксплуатации, но реально используется «старый» модуль. Я встречал забавные случаи, когда новая система «подымается» только на время приезда инспекции из материнской компании. Это тоже формальное внедрение;
- часть модуля находится в промышленной эксплуатации, однако «старый» модуль по-прежнему развивается для поддержания необходимой бизнесу функциональности. Именно посредством «старого» модуля достигается уменьшение функционального разрыва. Это пример слабого внедрения.
Ну и так далее, со всеми остановками.
- модуль находится в промышленной эксплуатации — количество усилий, которые тратятся на исправление ошибок, многократно меньше количества усилий, которые тратятся на развитие;
- большая часть старых модулей (подсистем), которые реализовывали схожую функциональность до внедрения нового модуля, выведена из эксплуатации;
- подавляющий объем новых требований бизнеса реализуется вовремя путем развития функциональности нового модуля (вокруг нового модуля не образуется слой «наколеночных» решений), т.е. не возникает существенного функционального разрыва.
ИТ-директорам, которым удается поддержать именно такой сценарий развития информационной системы предприятия, предлагаю (безо всякой иронии) ставить памятник при жизни. И этот памятник должен символизировать бессмертное изречение: «Надо очень быстро бежать вперед, чтобы оставаться на месте». А для того, чтобы чего-то достичь, нужно бежать ещё быстрей…
Поведенческие индикаторы прогрессора
- Концептуальное (системное) мышление:
- наблюдает несоответствия между текущей и прошлой ситуациями;
- применяет сложные концепции для анализа этих несоответствий;
- упрощает сложность — собирает идеи, вопросы, наблюдения в единое представление; определяет ключевой вопрос в сложной ситуации;
- создает новые концепции, в том числе по сложным системам;
- распознает внутреннее устройство системы и строит адекватные, по возможности простые модели.
- проявляет интерес к увеличению порядка в существующей системе (бизнес-процессе);
- выявляет слабые стороны и недостаточные данные и ищет информацию для поддержания порядка в системе (бизнес-процессе);
- разрабатывает и применяет комплексные системы для организации и отслеживания информации.
- сохраняет уверенность в ситуации неопределенности;
- изменяет способы поведения при изменении ситуации;
- признает ограниченность своих знаний, умений и навыков;
- использует возможности для расширения своих знаний, умений и навыков;
- владеет эффективными методами самообучения.
- оценивает степень завершенности результата и его соответствие поставленной цели;
- прогнозирует варианты развития событий;
- предвидит трудности и предполагает варианты путей по их преодолению;
- способен достигать поставленную цель, несмотря на препятствия;
- стремится получить наилучший результат из возможных.
- сознает пределы собственных полномочий;
- стремится самостоятельно определять свои цели, согласуя их с особенностями ситуации;
- принимая решение, оценивает степень риска;
- готов взять на себя ответственность за последствия предполагаемого решения;
- действует исходя из принятых на себя обязательств;
- учится на своих (и чужих) ошибках.
Примечание. Я не сторонник механистического подхода к оценке людей, поэтому изложенные здесь поведенческие индикаторы надо рассматривать как ориентиры, которые в совокупности должны дать более-менее четкий портрет.
Прогрессоры
Итак, мы вплотную приблизились к ответу на вопрос: что надо сделать, чтобы внедрение было результативным? Для начала отвечу так. Надо обуздать системную сложность, причем дважды: во-первых, живой системы, то есть организации, а во-вторых, внедряемого прототипа, который сам по себе является сложной информационной системой. Совет в духе «хочешь быть здоровым — будь им».
А вот чтобы сделать это с высокой степенью гарантии, вам придется найти практикующих системных аналитиков с очень высоким уровнем компетенции, которых я далее буду именовать «прогрессорами» — как людей, способных к реализации мощных прорывных проектов.
Во-первых, прогрессор должен обладать великолепным концептуальным (системным) мышлением. Он в состоянии распознавать внутреннее устройство системы и строить адекватные модели. Он умеет упрощать сложность — собирает идеи, вопросы, наблюдения в единое представление. Он умеет задавать «прорезающие» вопросы в сложной ситуации.
Во-вторых, прогрессор должен непрерывно заботиться о качестве в широком смысле этого слова. Он нацелен на увеличение порядка в существующей системе (бизнес-процессе). Он непрерывно выявляет слабые стороны и изъяны в данных и ищет информацию для поддержания в них порядка.
В-третьих, прогрессор чувствует себя в изменяющейся ситуации как рыба в воде. Он сохраняет уверенность в условиях неопределенности. Он признает ограниченность своих знаний, умений и навыков. Он впитывает в себя всё новое, как губка.
Он неплохой коммуникатор — по крайней мере он заинтересован в результативности взаимодействия и умеет не вызывать раздражения у собеседников, представляя свою точку зрения.
В довершение всего прогрессор результативен. Он способен достигать поставленную цель несмотря на препятствия, причем стремится получить наилучший результат из возможных.
Как выбрать прогрессора
-
1) схожего масштаба с нужной вам тематикой (отлично);
2) схожего масштаба с другой тематикой (хорошо);
3) меньшего масштаба (удовлетворительно).
Второй вариант, как это ни странно, не сильно отличается от первого. Объясняется это тем, что компетенции практического системного анализа очень слабо привязаны к предметной области. Основные риски здесь будут в том, что инструмент, которым владеет прогрессор, не подойдет для вашего проекта.
Третий вариант опасен по двум причинам: во-первых, увеличение масштаба системы может потребовать от кандидата принципиально новых умений, а они пока не доказаны; во-вторых, ограничения по инструменту тоже могут оказаться неприемлемыми.
Проверить достижения кандидата, а также убедиться, что это именно его достижения, можно только одним способом: нанести несколько визитов в те организации, в которых он успел потрудиться. И в каждой несколько раз без посредников поговорить с очевидцами проекта (именно с очевидцами, а не с теми, кто о нём «слышал»). Идеально, чтобы среди них был сотрудник ИТ-службы, отвечавший за внедрение проекта со стороны компании. Неплохо подойдет и один из ключевых бизнес-пользователей.
Спрашивайте всё, что вам интересно, но не забывайте своей цели: вам нужно понять, что именно ваш кандидат создал модель бизнес-процесса, которая результативно внедрена, невзирая на высокую динамику требований в процессе внедрения (еще раз посмотрите на критерии результативного внедрения!). И на всякий случай проверьте, что он подходит под описанный мной «портрет компетенций». Если вы обнаружите сильное несоответствие, то велика вероятность, что вел проект кто-то другой. Попробуйте найти именно его… И наконец, получите весомые гарантии того, что выбранный вами кандидат (именно он!) и будет вести ваш проект до окончания внедрения.
После результативного внедрения
Начав работать с прогрессором, вы должны понимать, что после результативного внедрения он обязательно будет искать себе другой проект. Поэтому заранее позаботьтесь о защите своих инвестиций.
Во-первых, добейтесь, чтобы люди, которые будут отвечать за развитие проекта после внедрения, появились в проекте как можно раньше (на рис. 2 «инженер»). Прогрессор почти наверняка даст вам трезвую оценку, есть ли в проектной команде такие люди. Только продолжительная совместная работа с прогрессором в ходе внедрения позволит «инженеру» в будущем отвечать за самостоятельное развитие модуля. Это единственный вариант трансляции знаний, который позволит вести устойчивое развитие модуля в соответствии с заложенными моделями, архитектурой и дизайном.
Во-вторых, найдите прогрессору следующий проект в своей организации, если это возможно. Каждый проверенный прогрессор — это тот актив, который помогает вам развивать бизнес. Или хотя бы сохраните партнерские отношения с ним. Он вам очень пригодится, если автоматизированный в модуле бизнес-процесс придется еще раз кардинально изменять.
Один в поле не воин
- объективная необходимость проекта для организации;
- внятное управление проектом со стороны заказчика;
- слаженная проектная команда, которая работает с прогрессором;
- достойный уровень инструментального оснащения (т. е. «прототипа»);
- гибкие технологии проектного управления…
Но будьте уверены: если вы действительно нашли прогрессора, если он согласился работать вместе с вами над проектом, если через полгода совместной работы вы еще вместе, то вероятность успеха проекта очень высока.
В ходе данного этапа организации внедрения проекта выполняется сбор основных сведений о текущей ситуации у Заказчика, проводится интервьюирование ключевых пользователей будущей системы, изучение текущих учетных систем. По итогам предпроектного обследования структурируется полученная информация, которая позволяет оценить сроки, фазы и этапы всего проекта, а также его бюджет. В качестве итогового документа предоставляется «Отчет об экспресс-обследовании».
Основной ценностью этапа предпроектного обследования для Заказчика является получение зафиксированного скоупа проекта и знакомство с ключевыми участниками проектной команды (руководитель проекта, архитектор)
2. ЭТАП 2. Моделирование внедрения проекта 1С
Суть процесса моделирования при внедрении проекта 1С – наложение реальных процессов организации на имеющиеся механизмы отражения подобных бизнес-процессов в типовой конфигурации от 1С и фиксация функциональных разрывов – различий, требующих донастройки или серьезной доработки системы.
На данном этапе разрабатывается функциональная модель целевой системы, формируются требования к подготовке отчетности, утверждаются состав требуемых аналитических разрезов.
Выполняется проработка решений по способам автоматизации с подготовкой прототипа системы и написанием документа «Концептуальный дизайн», в котором фиксируются и описываются все принятые решения на типовом функционале. Будут проведены демонстрации практической реализации различных процессов и настроек в демо-базе, отработаны сквозные примеры, соответствующие специфике бизнес-процессов Заказчика.
Сам процесс моделирования в значительной части проходит в плотном взаимодействии сотрудников Исполнителя и Заказчика: сотрудники Заказчика активно вовлекаются в работу, производится обучение ключевых сотрудников и экспертов Заказчика. Со стороны Заказчика выполняется уточнение и актуализация учетных политик регламентированного и управленческого учета, действующих регламентов и процессов управления. Состав регламентов определяется внедряемыми подсистемами.
Концептуальный дизайн – документ, содержащий описание бизнес-процессов, подлежащих отражению в системе. По сути, это описание системы «To be».
Реестр функциональных разрывов – документ, содержащий перечень требований на доработку с табличным представлением результата.
Моделирование внедрения проекта системы 1С ведётся по блокам, короткими итерациями при наличии активной взаимосвязи по схеме:
создание модели → демонстрация → корректировка модели
3. ЭТАП 3. Проектирование внедрения 1С
На данном этапе положения и требования, зафиксированные ранее, преобразуются в конкретные проектные решения. Проектные решения описываются в частных технических заданиях (ЧТЗ) на каждую модификацию (доработку).
Несмотря на кажущуюся обязательность данного этапа внедрения проекта 1С, наша практика показывает отсутствие необходимости составления единого технического задания и технического проекта на всю систему после выполнения этапа «Моделирование».
Т.к. все функциональные разрывы с типовой конфигурации 1С описываются по итогам этапа «Моделирования», этой информации нашей команде в большинстве случаев достаточно для реализации всех доработок системы.
С учетом тренда на максимальное использование типового функционала при внедрениях, мы стараемся идти по пути минимального количества доработок системы, при этом используется механизм расширений, сохраняющий типовую конфигурацию для беспроблемных обновлений.
Тем не менее в ряде случаем мы включаем данный этап в проект, особенно если предстоит значительная адаптация системы. Выходным документом данного этапа является документ «Техническое задание» (ТЗ), частное технические задание или «Технический проект» (ТП).
4. ЭТАП 4. Разработка и тестирование информационной системы
На данном этапе реализуются доработки в информационной системе, после чего по каждой доработке проводится процедура приемо-сдаточных испытаний (ПСИ). При этом проводится как сценарное тестирование информационной системы, так и нагрузочное (при необходимости).
В случае проведения нагрузочного тестирования информационной системы и подготовки его результатов необходимо привлечение специалистов, компетенция которых подтверждена компанией 1С (сертификация 1С:Эксперт по технологическим вопросам).
5. ЭТАП 5. Обучение пользователей типовой конфигурации 1С
На данном этапе производится обучение участников проектной команды и подготовка пользовательской документации.
В соответствии с разработанным и согласованным планом обучение производится как в очном формате, так и в формате вебинаров. Обучение включает в себя как теоретическую, так и практическую часть.
На основании нашего опыта, мы рекомендуем проводить обучение сотрудников, занятых на проекте как можно раньше, возможно, даже до начала предпроектного обследования. Это позволит сотрудникам быть максимально вовлеченными в процесс за счет лучшего восприятия системы и ее особенностей.
6. ЭТАП 6. Подготовка к эксплуатации информационной системы
На данном этапе выполняется:
· развертывание ИС в рабочей среде;
· настройка системы для отражения всех включенных в проект бизнес-процессов;
· настройка прав и ролей пользователей;
· перенос исторических данных из ранее использовавшихся систем;
· интеграция со смежными системами;
· выверка и корректировка данных;
· развертывание системы на рабочих местах пользователей.
7. ЭТАП 7. Опытно-промышленная эксплуатация информационной системы
Опытная эксплуатация информационной системы проводится Заказчиком при поддержке Исполнителя на реальных данных посредством ввода данных и получения необходимой отчетности одновременно в двух системах – исторической и создаваемой с целью найти отклонения в работе функционала новой информационной Системы. Срок опытной эксплуатации информационной системы устанавливается по согласованию сторон в пределах от 1 до 3 месяцев.
На стадии опытной эксплуатации информационной системы производится поддержка и сопровождение системы силами Исполнителя: происходит устранение замечаний, производится дополнительное обучение пользователей в процессе их работы в реальных условиях, осуществляется консультационная помощь при работе с системой.
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
В системе 1С 8.3 Бухгалтерия предприятия 3.0 для финансовых договоров используются графики расчетов платежей (оплат).
Описание схемы взаимодействия описываемого бизнес-процесса с другими бизнес-процессами представлено на Рисунке 1.
Рис. 1 Схема ведения договоров в 1С 8 БП
Для финансовых договоров в автоматическом режиме в системе заполняются графики расчетов платежей.
При необходимости, график в 1С 8 БП изменяется в ручном режиме.
На основании введенных в график данных автоматически создаются заявки на оплату.
После проведения в программе 1С:Бухгалтерия предприятия документов «Списание с р/сч» и «Поступление на р/сч» график оплаты по договору может быть обновлен (по кнопке «Обновить фактические данные»).
2. Требования к автоматизации (доработке) для графика оплаты в 1С
В конфигурации 1С:Бухгалтерия предприятия автоматизируются следующие функции:
· создание заявок на оплату на основании данных графика оплаты платежей;
· оповещение ответственного за договор о созданном документе ЗНО с возможностью ручного закрытия оповещения по кнопке «Ознакомлен», а также дополнительная возможность – оповещение по e-mail при необходимости;
· для строки графика оплаты по договору должна быть возможность выбора статьи БДДС, ЦФО и Бизнеса;
· обновление фактических данных в графике договора при фактических движениях по договору, в т.ч. неденежных.
Должен быть признак, указывающий, что заявки на оплату формируются в соответствии с графиком оплаты платежей или в ручном режиме. Для договоров, у которых указано автоматичское формирование ЗНО должна быть возможность ручного создания ЗНО.
3. Реализация бизнес-процесса в системе 1С 8 БП
Заполнение поля «Ответственный» представлено на Рисунке 2.
Рис. 2 Заполнение поле Ответственный в 1С 8 БП
В 1С 8.3 БП в договорах с видом формирования платежей «График», поля «ЦФО», «Статья ДДС» и аналитика раскрытия «Бизнес» заполняются на закладке «Расчеты». На закладке «График расчетов» в строках по умолчанию заполняются значения с закладки «Расчеты», с сохранением возможности ручной корректировки (Рисунок 3).
Рис. 3 Заполнение ЦФО и ДДС по графику оплаты в 1С
Помимо ЦФО, статьи ДДС и реквизита «Бизнес», в графике также заполняются даты начисления и списания денежных средств. При заполненном поле «Условие оплаты» график можно пересчитать согласно заданному условию по кнопке «Пересчитать график». Система контролирует равенство суммы начисления и оплаты на основании договора.
В системе 1С график оплат в финансовых договорах рассчитывается автоматически согласно информации на закладке «Расчеты» (Рисунок 4).
Рис. 4. Заполнение закладки "График расчетов" в финансовых договорах
После того как в 1С 8.3 БП провели документы поступления / списания с расчетного счета, связанные с заявками на оплату и с планируемым поступлением ДС, необходимо обновить данные графика оплаты по договору на фактические (по кнопке «Обновить фактические данные»). В типовом варианте программы 1С:Бухгалтерия предприятия фактические данные отражаются только в колонке «Основной долг – Возврат». Для корректной работы с графиком оплат в 1С была выполнена доработка – на основании фактических данных (по кнопке «Обновить фактические данные»), в графике данные пересчитываются по всем видам платежей (Основной долг, Проценты, Комиссия, Штрафы) (Рисунок 5).
Рис. 5 Доработка отображения данных в финансовом договоре в 1С 8 БП
Если на дату оплаты в системе 1С 8 БП не будет отражен факт к заявке на оплату, то в графике оплаты платежей появятся суммы, выделенные красным цветом и возникнут ошибки при проведении договора (Рисунок 6).
Рис. 6 Отсутствие фактических данных на дату оплаты
Если сумма по графику оплаты платежей больше, чем сумма договора, система проинформирует об этом и запретит проведение договора до того момента, пока график не будет актуализирован (Рисунок 7).
Рис. 7 Превышение оплат над получением в 1с 8.3 БП
Если в ранее проведенном факте меняется сумма, то и в графике договора она также меняется (по кнопке «Обновить фактические данные») (Рисунок 8).
Рис. 8 График расчетов платежей до обновления фактических данных
Далее представлен процесс корректировки и обновления данных в графике оплаты по договору (Рисунки 9-11)
Рис. 9 Сумма в документе до корректировке
Рис. 10 Сумма в документе после корректировки
Рис. 11 График расчетов платежей после обновления фактических данных
4. Выполненные доработки системы 1с 8 БП
Описание функционального разрыва
1. Удалено автоматическое заполнение в создаваемой карточке договора поля «Ответственный» значением пользователя, который создал эту карточку
2. Сделано поле «Ответственный» обязательным для заполнения
3. Оповещение ответственного за договор пользователя о автоматическом создании ЗНО по графику оплаты с возможностью закрытия оповещения по кнопке «Ознакомлен»; настройка оповещений по e-mail
4. На основании фактических данных (по кнопке «Обновить фактические данные»), в графике оплаты платежей данные пересчитываются по всем видам платежей (Основной долг, Проценты, Комиссия, Штрафы)
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
Читайте также:
- Неизвестная ошибка 2147467259 в web клиенте 1с
- Автоматическое заполнение ячеек при выборе значения из раскрывающегося списка в excel vba
- Ошибка clr 80004005 работа программы будет прекращена cyberpunk 2077
- Comodo защита браузеров выскакивает
- Как в 1с оформить возврат неиспользованных подотчетных сумм