0: Коллеги, добрый день.
1: Меня зовут Светлана Шереметова, моего коллегу Владимир Кудимов. Мы представляем департамент ерпи решений компании 1 эс апрель софт. Сегодня проводим для вас вебинар, который касается такой темы, как риски проекта.
2: Несколько вводных слов скажу, потом передам слово Владимиру. Ну, собственно говоря, почему решили такой вебинар сделать и вообще, откуда, каким образом он родился? Мы на протяжении уже получается
3: 18, 17 лет ведём проектную деятельность. Основной продукт, который мы внедряем. Это сейчас система 1 с ерпи. Ранее была система 1 с упп. Кроме того,
4: В качестве базы используем другие корпоративные решения фирмы 1 с. Вот, ведя проектную деятельность, у нас, в общем то, уже сложилось совершенно чёткое понимание, какие риски наиболее вероятные возникают в течение того или иного
5: Проекта, откуда они берутся, что с ними делать. И вот этой информацией мы хотели бы с вами поделиться сегодня, потому что как мы считаем, что все-таки проект это
6: Это как минимум командная работа, да, это работа 2 сторон, и каждая из сторон должна быть подготовлена. Каждая из сторон должна иметь необходимый багаж знаний и понимания для того, чтобы проект
7: Прошёл успешно и для того, чтобы в итоге получить те результаты, которые хочет получить бизнес и достичь те цели, которые необходимо достичь.
8: По орг вопросам ещё пару слов.
9: У нас сейчас с вами основная часть, в принципе, вы и в течение неё уже можете готовить ваши вопросы и писать их либо в чат, который у вас у всех есть, либо вы можете задавать вопросы на вкладке. Вопросы это
10: Верхняя панель вашего экрана. Все эти вопросы мы постараемся в конце разобрать. Если у вас вдруг пропадёт звук или пропадёт изображение, пропадёт картинка, то 1, что стоит сделать, это перезагрузить.
11: Страницу в основном это помогает. Если это не помогло, то, пожалуйста, пишите в чате ваши контактные телефоны. Как вас зовут? Наша служба поддержки с вами свяжется и постарается помочь решить вот эту техническую проблему.
12: Я тогда передаю слово Владимир, тебе Владимир, когда начнёт вещать, пожалуйста, поставьте в чате плюсы, что его видно, слышно. То есть главное, чтобы его было видно, слышно и была видна картинка. Владимир, подключайся, пожалуйста.
13: Да, добрый день. Итак, как сказала Светлана вести вебинар буду я, Владимир Кудимов, руководитель проектов компании апрель софт. Вот сегодня мы рассмотрим такую тему, как риски проекта и разберём некий практический кейс.
14: Которые возникали на живых проектах. И какие способы решения этих кейсов может быть. Итак, начиная любое новое дело, люди сначала составляют план, вот, то есть, но кроме состав
15: Plan. Ещё желательно и оценивать и сложности, которые могут повлиять на его исполнение, потому что любой, самый идеально составленный план будет натыкаться на какие-то преграды для того, чтобы придерживаться, как бы заранее запланировать, как мы будем
16: Этого составленного плана. Желательно предположить, как мы будем действовать в той или иной сложной ситуации. Проект в этом смысле можно воспринимать тоже как новое дело. Сложности, которые возникают в ходе его проведения. Это и есть риски проекта.
17: What существует ряд специальной литературы, управлении рисками проекта, и, возможно, вы уже с ней работали, но чаще всего мы используем, как бы мы и компания 1 с использует свод знаний по управлению проектами каждый.
18: Проект имеет как минимум тройное ограничение. Так все вроде пошло. То есть это сроки, стоимость и содержание. Вот, но есть и дополнительное ограничение проекта.
19: Риски проекта, ресурсы и качество проекта и получаем вот такую вот шестигранную звезду. Вот даёт следующее объяснение. Изменение требований к проекту или целей проекта может быть может вызвать дополнительные риски, а риски, в свою очередь, могут повлиять
20: Содержание проекта, сроки или бюджет проекта. Вот как я уже сказал, в ходе доклада мы постараемся рассмотреть ряд рисков, которые часто возникают на проектах. Их воздействие на ограничения проекта и рассмотрим способы, которые позволяют минимизировать возникновение возни.
21: Возникшие риски воздействия, их способы воздействия на проект.
22: Как я уже сказал, использовать мы будем как бы стандартную документацию проекта. То есть у нас ведётся карточка риска и карточка риска представляет из себя это как бы некий номер риска, реестр риска, описание риска и его степень влияния на параметры проекта, степень влия.
23: Не для каждого проекта может быть уникально. Вот. Поэтому мы её сильно на это обращать внимание не будем. Ну, как здесь вот написано о том, что каждый риск, допустим, этот риск, он влияет на влияние, на сроки, у него высок.
24: На стоимость. Возможную стоимость проекта. Степень влияния высокая, на изменение содержания проекта среднее влияние. Итак, 1 риск, который мы будем рассматривать, это замыкание проект процессов на
25: На руководящем звене заказчика или на it службе заказчика без привлечения пользователей.
26: Так какие требования заказчика могут провоцировать появление этого риска, ну, как бы стандартные требования это не надо отвлекать наших сотрудников, вам для контактов будет выделен отдельный специалист или it специалист, или ключевой руково.
27: Водитель или представитель айти службы, который хорошо знает нашу систему, и он может ответить на все ваши вопросы. Или это новый раздел учёта. Сотрудники все равно не могут вам ничего сказать. Я хочу, что все изменить.
28: Пользователи вам ничего не могут сказать, так как у них нет стратегии, и только я её вижу. Поэтому слушайте меня, а уже что у нас получится? Мы будем отдавать сотрудникам как бы в работу. Вот возможен вариант на следующий
29: Что нам надо просто повторить ту систему, которая раньше была на решении 1 с или на другом решении. Вот. И для этого мы вам предоставим свою систему, а вы её просто напросто переведёте на новую платформу и с точки зрения заказ
30: Вот эти подходы, которые он излагает, они кажутся разумными, он минимизирует трудозатраты сотрудников на проект, то есть даёт минимально, как бы, как ему кажется, минимально необходимую команду. А остальные люди, которые работают на предприятии, должны в 1
31: Прийти и начать работать на новой платформе, практически не почувствовав никаких изменений, которые произошли вот это, с точки зрения заказчика, с точки зрения исполнителя подобный подход приводит к огромному количеству неопределён.
32: То есть, во первых, непонятно, что действительно требуется от будущей системы, какая должна быть её функциональность. Вот непонятно, какие текущие настройки, которые есть, ну, в текущей
33: На предприятии актуальны, а которые и действительно используются пользователями, востребованы, а которые являются просто пережитками, какие пользователи используют дополнительные средства обработки информации, дополнительные эксель таблицы.
34: Ещё какие-то расчёты, которые они производят при подобном подходе. Эта информация теряется. Естественно, она не будет реализована в новой системе, какие требо пользователи выдвигают требования к эргономике, системы к интерфейсам.
35: Система.
36: И, соответственно, когда мы начинаем проект и проводим его, его оценку, эти неопределённости, так как они, мы знаем, что они возникнут, они должны быть оцифрованы, они будут
37: Заложены в сроки проекта стоимость проекта. И если заказчик пытается сократить стоимость проекта, ну, это чаще всего повлечёт за собой сокращение содержания проекта. Вот будет реализовано не все, что сотрудниками будет в конечном итоге затребовано.
38: А будет реализовано то, что будет входить в ограниченные рамки проекта, которые будут прописаны на этапе заключения договора. Вот, а есть ли возможность собрать позиции заказчика исполнителя вместе и найти компромисс. Мы считаем, что это возможно, это возмо,
39: Можно при условии, что каждая сторона проявит гибкость и будет подобран необходимый вариант проведения работ на проекте. Вот, потому что проект изначально нацелен на создание уникального продукта, который будет учитывать уникальные особенности предприятия уника.
40: Его требования к системе работы людей на этом предприятии и какие мы видим решения.
41: Так, не туда, секундочку. Вот дальше мы также будем рассматривать возражения и предполагаемые
42: Как бы проблемы и предполага возможное решение. Вот. Итак, берём 1 возражение, не надо отвлекать наших сотрудников, там для контактов будет выделен айти специалист, который хорошо знает систему, и он ответит на все ваши вопросы. Ну,
43: То есть получается, что руководитель предприятия пытается реализовать идеальную систему с точки зрения 1 человека, ну, который будет её принимать, и она не будет отражать потребности тех людей, которые работают на предприятии.
44: В нашей практике уже был подобный пример, когда мы разрабатывали для крупной холдинговой структуры систем систему планирования продаж производства. Вот со стороны заказчика была выделена команда, которая
45: Ну, написал некий концепт, она определила систему планирования, которая учитывала и, скажем так, и потребности покупателей в разрезе номенклатуры сроков поставки периодич.
46: Поставки, то есть это все было сделано через определённые коэффициенты. Можно было анализировать очень много показателей в отчётности, но люди, которые работали на этом предприятии, когда столкнулись с данной систе,
47: Планирование не смогли её понять, и на то есть они не могли понимать, как выставлять те или иные коэффициенты, от чего они зависят, как они рассчитываются, с какой периодичностью или по какому событию их надо выставлять.
48: Они не могли осознать, что как показатели, которые выводятся в отчётности, что они показывают и как им реагировать на их изменения, то есть, если показатель уходит в красную зону, какие действия необходимо предпринять, чтобы исправить ситуацию.
49: То есть, в конечном итоге подсистема планирования, она была реализована, она проработала, скажем так, только этап опытной эксплуатации, пока осуществлялась высококвалифицированная поддержка. Вот, но, как мы знаем, уже в последующем от этой
50: Под системы пришлось отказаться, потому что пользователи не могли её обеспечивать, она не отражала их потребности.
51: Вот, соответственно, ну, какие мы видим проблемы при работе с данным возражением. Ну, мы, у нас нет информации о действительных потре, требованиях пользователей. Вот происходит замораживание теку.
52: Проблем по ведению учёта в рамках функционала предыдущей системы. То есть если сейчас пользователи осуществляют ряд расчётов вручную при помощи эксель таблиц или собирают отчётность вручную, то это не выявится в рамках проекта.
53: И, соответственно, они останутся со своими эксель таблицами, а система будет отражать только требования того человека, который будет выделен в качестве её куратора. Вот доработка системы по малозначительным для пользователя операциям и вполне вероятно,
54: Что будет перенесён функционал, который пользователю на самом деле не нужен. Он был разработан в предыдущей системе. Ключевому сотруднику кажется он важным, но в настоящий момент он не используется. Ну так как поменялись процессы, поменялись потре.
55: Вот, но ключевой пользователь об этом может и не знать. Вот реализация вообще мёртвого функционала. То есть функционал, который тоже был создан, но в настоящий момент он совершенно не востребован пользователями. Вот. Или это какие
56: Это дополнительные проверки, запреты, ну, то, что как бы должно улучшать действия пользователей, или мы относим к этой, ну, мёртвому функционалу онлайн обмен. То есть, чтобы информация из 1 системы сразу отображалась в другой, что
57: На самом деле требует большой производительности оборудования системы, но не всегда даёт необходимый эффект.
58: Так какие мы видим возможные подходы к решению по данному возражению? Ну, во первых, наше требование о том, что доступ к пользователям и руководителям подразделений должен быть обязательным, потому что только они определяют требования к системе от функционал.
59: Которая должна быть до печатных форм и отчётов, которые она должна выдавать. Вот можно от этих групп людей выделить ответственных, ну, отдельных, ответственность ответственных, которые будут принимать систему, ну и определять требования к ней.
60: Она должна реализовывать вот заказчику лучше до начала проекта продумать наличие со своей стороны проектной команды, куда будут входить и ключевые пользователи, которые наделены полномочиями по принятию решений, и они
61: Могут обеспечить их продвижение в коллективе, чтобы люди приняли и начали работать с системой. Вот если в этой команде будут люди с предыдущим опытом работы аналогичных внутренних проектов, это будет замечательно. Вот пользователи
62: Могут самостоятельно подготовить предварительную информацию по набору отчётов печатных форм там, расчётов, которые они используют в своей работе. Вот, то есть они могут выставить свои требования к системе.
63: Которые должны быть реализованы в рамках проекта. Также заказчик с исполнителем должны могут договориться о том, что исполнитель на первых этапах обеспечивает наличие функциональности.
64: И переходит на всякие улучшения и бантики. Ну, переделаны бантики, системы потом, то есть на последующих этапах. То есть, когда люди уже поработают в системе, привыкнут, поймут, что она может делать, как
65: Поймут, как вообще происходит в ней работа, и только потом уже можно будет прорабатывать эргономику путём, путём создания армов, для улучшения интерфейсов, ну и для ускорения ввода данных в систему. Вот.
66: Упрощение там, регистрация операций, упрощение получения отчётности.
67: Так, переходим ко 2 возражению, что это новый раздел учёта и сотрудники вам все равно ничего не могут сказать.
68: Вот предполагаемые проблемы, которые мы видим, возможно, что ряд функций для нового раздела учёта сотрудники уже выполняют. То есть, ну, не появился он из воздуха. То есть все равно какие-то запросы, вероятнее всего, уже были и сотрудники их отраба.
69: И, соответственно, это накопленный опыт, он может потеряться в ходе проекта, вот, и без практической работы. То есть теоретически требования руководителя к функционалу могут оказаться излишними и не смогут поддерживаться текущим штатом сотруд.
70: Что это такое может быть? Ну, то есть, допустим, дополнительная детализация проработки ведения учёта, но эти требования, они могут быть не отработаны.
71: Потому что люди могут, не, ну, сотрудники, которые должны обеспечивать эту детальный ввод информации, могут не знать, где её брать, кто её должен предоставить. То есть, опять же, непонятно, кто должен её вносить, потому что трудоёмкость ввода данных
72: Увеличивается. Соответственно, на это должно быть выделено либо дополнительное время, либо дополнительные ресурсы. Вот подобная детализация ввода информации, там, допустим, она может привести к тому, что произойдёт быстрый прирост.
73: Будут возникать сложности с её хранением, архивированием. Вот излишние запреты, которые могут быть навешены на систему, они могут не давать понимания, в чем пользователь совершил ошибку. То есть почему у него не получается операция
74: Какие действия необходимо предпринять для того, чтобы исправить ситуацию и ввести необходимые данные. Вот, ну и, соответственно, если будут разработаны очень сильно нагруженные формы, которые будут отображать много, много показателей, которые буду
75: Очень быстро обновляться там чуть ли не в режиме онлайн. Очень часто это приводит к тому, что быстродействие системы понижается из за перегруженности форм, из за постоянных запросов, данных в системе, которые могут тормозить.
76: Как работу данного пользователя, так и системы в целом. Так какие мы видим возможные подходы к решению, ну, по данному возражению. Ну, во первых,
77: Достигать цели поэтапно. На 1 этапе поль исполнитель внедряет типовой функционал программного продукта с учётом потребности руководства к отчётности. Вот, и, соответственно, требований к отражаемым операциям и уже на последующих этапах после
78: Того, как пользователи поработают, привыкнут, уже производится доработка системы, исходя из реальных потребностей, из реальных потребностей руководителей и возможностей пользователей. Вот, то есть, как мы обычно делаем, ну,
79: Во первых, работа идёт до получения в системе 1 результата, который можно анализировать. То есть отчётность, которая уже показывает, как работает предприятие. Вот по нашему опыту, через 2 недели работы обычно пользователи снимают требования
80: К интерфейсу, они к нему привыкают, забывают свою старую систему, вот уже не представляют, как в ней работать. Ну, если они не будут к ней постоянно обращаться. Вот. И, соответственно, требования к интерфейсам новой системы снимают. Вот.
81: И обращают внимание пользователи в основном только на те вещи, которые действительно мешают им работать, где у них затруднён ввод информации, где им трудно получать информацию. Вот, и подобный подход позволяет нам как бы
82: Провести анализ, насколько глубина той аналитики, которая была заложена в систему, она действительно требуется, действительно ли пользователи ведут анализ по всем показателям, которые заложены.
83: Или работает только с аналитикой верхнего уровня. Вот.
84: Потому что, ну, как мы уже встречались на своих проектах о том, что большая глубина детализации, допустим, при проектировании системы бюджетирования, она может помешать и пользователю, и заведения информации, то есть запланировать со, с этими детальными показателями. Вот, ну,
85: Соответственно, это идёт слож, ну, как бы, не сложность, сложность анализа полученной отчётности, вот, и анализа действий, которые необходимо принять для исправления. Вот очень часто люди останавливаются только, навер,
86: Уровне, ну то есть на том уровне, который позволяет им принять решение, ну, произвести действия. Вот.
87: Переходим к следующему возражению по 1 риску. Это что? Нам надо просто повторить нашу систему на платформе 1 с и мы вам передадим нашу, ну, текущую систему, а вы её повторите. Вот такое возражение чаще всего возникает при переходе со старых версий платформы.
88: Допустим, 7, 7 или с старых релизов, ну, как управление торговлей 10 на новую платформу. Или сейчас актуально. Это как переход с другого софта, который был на предприятии, на
89: Продукты 1 с вот какие мы видим проблемы. То есть это попытка реализовать текущую систему заказчика на платформе 1 с приведёт к отказу от, ну, чаще всего приводит к отказу от использования типового решения и
90: Это решение, которое будет взято за основу, очень сильно дорабатывается, ну либо полностью, либо отдельные блоки, либо интерфейс. Подобная реализация затрудняет.
91: Следующую поддержку сопровождения, ну, как бы, как и текущей компании. Если предприятие захочет поменять компанию, то, значит, и следующей компании. Вот если он происходит изменение требований законодательства, то это
92: Необхо. Эти требования законодательства необходимо будет воссоздать вручную, так как использование типовых обновлений для сильно изменённой системе чаще всего невозможно. Вот система будет обладать минимальным функционалом общего назначения, то есть она будет зато
93: Точно под то, что было раньше его. Если вдруг возникают новые запросы, ну, допустим, у предприятия появились взаиморасчёты в уе. Или появились валютные операции, то, которых не было в старой системе, то этот функционал придётся каждый раз дорабатывать.
94: При возникновении такой потребности, вот при разработке, при повторении старой системы могут быть не использованы новые возможности, которые есть в решениях 1 с, ну то есть мы повторяем только то, что было
95: Какие мы видим возмо подходы к решению.
96: По данному возражению. Итак, ну, собирать новую систему или отдельные блоки лучше используя библиотеку стандартных подсистем. Вот. То есть 1 с выпустил такой универсальный механизм, который позволяет собрать
97: Скажем так, уникальное решение для данного предприятия, но которое сделано уже уже из готовых блоков. Вот, то есть, при помощи этого Функ, ну, функции, при помощи этих возможностей, мож.
98: Реализовать требуемый функционал. Вот, и уже приступить к рабо, к проработке интерфейсов путём создания отдельных армов, которые повторяют интерфейсик прежней системы. Вот у нас был опыт проведения подобных решений, то есть нами была
99: Создана для крупных холдинговых структур, то есть отдельные подсистемы, допустим, учёта приходных документов или система первичной обработки платежей. Ну, эти системы нужны были для того, чтобы не грузить предварительными расчётами первич.
100: Системы, оставить расчёты в промежуточный системы и загрузить уже конечный полученный результат. Вот, то есть эти работы выполнялись именно с использованием библиотек стандартных подсистем. Вот они были выполнены
101: Установленные сроки, то есть устроили заказчика по функциональности, прорабатывали только отдельные интерфейсные вещи. Вот и каждая подсистема была создана, и
102: Передана в эксплуатацию, ну то есть заказчику в пределах 160 часов. Также возможное решение это оставить прежнюю систему, но интегрировать её в корпоративную сеть.
103: Без обмена. Вот, то есть, ну, для того, чтобы организовать обмен, допустим, сайтом. Вот, то есть можно создать промежуточную базу, это самое, в качестве шины эта база будет обмениваться с текущей системой и
104: Помощь веб сервисов проводить онлайн обмен сайтом, ну там отвечая на его запросы. Вот.
105: Или же использовать просто типовые шины, которые уже существуют. То есть мы сохраняем функциональность старой системы, и мы создаём просто промежуточную буферную систему, которая позволяет нам реализовать все необходимые, все, но
106: Новые возможности использовать все новые возможности платформы, но при этом не меняя систему. Вот
107: Также можно изучить возможности типовых решений, выбрать решения, которые максимально близко реализует типовой требуемый функционал. Ну, как мы знаем, 1 с выпускает очень много, точнее, партнёры 1 с выпускают очень много
108: Скажем так, дополнительных решений, которые развивают функционал уже типового решения.
109: Итак, с этим риском мы закончили. Теперь переходим к новому риску, который может возникать на проекте. Так, секундочку, я пока ознакомлюсь с замечаниями.
110: Итак, следующий риск, который мы рассмотрим, это несвоевременный неоперативный ввод информации. Вот есть риск несвоевременного внесения информации в систему. Цели автоматизации достигнуты не будут степени влияния. Они, как я уже сказал, индивидуальные. Поэтому, м,
111: Пока опустим.
112: Что в работе сотрудников заказчика может провоцировать появление этого риска. Ну, во первых, чаще всего работа в новой системе, она осуществляется с параллельного ввода данны.
113: Старую систему. Вот, и сотрудники заносят данные только в старую систему, игнорируя работу в новой системе. Ну, потому что они не успевают. Ну, причины могут быть разные. Вот следующий причина, это работа в новой системе не спланирована.
114: Заказчика, то есть заказчик не определил сроки ввода проверки информации. Вот не составлен план, график проведения работ для сотрудников заказчика. И вот проверка информации осуществляется только по остаточному принципу.
115: Также причиной может быть то, что в проект заложили более глубокую детализацию данных в системе. Вот это требует увеличения работы персонала. Численность персонала увеличена не была. Вот реструктуризация деятельности предприятия не проводилась.
116: И, соответственно, люди не успевают вводить как пример. Можно, ну, привести о том, что, допустим, предприятие решило вести детальный учёт канцтоваров. То есть оно приходует каждую единицу канцтовара, который пришёл
117: Перемещает его на другие подразделения, учитывает сроки, скажем так, выдачи. Дополнительная работа, дополнительная работа, но чаще всего она не окупается. Ну, потому что стоимость карандашей, которые или ручек, которые были переданы, они
118: Ниже, чем стоимость времени сотрудников по их учёту. Вот и ещё 1 из причин. Сотрудники не уделяют внимание проверке внесённых данных.
119: Которые появились в системе автоматически. Вот, то есть введённые начальные остатки, перенос данных в другие системы, интеграция с другими системами. Вот почему сотрудники могут так поступать. Вот, ну, 1 из причин это то, что сотрудники предпри,
120: Не верят в необратимость процесса перехода, вот и при работе стараются работать больше исходя из старых правил, принципов, подходов. Новая система им кажется сложной, непонятной, это обычная человеческая реакция на резкие измене.
121: Вот она возникает у большинства людей, но сотрудники боятся сказать о своих проблемах при работе с новой системой, предпочитают тихо саботировать её, вот, оставляя все на последнее.
122: На последнюю, в последнюю очередь реализации. Вот. И надо понимать, что эта ситуация хоть и временная, но она болезненно сказывается на процессе внедрения системы. Вот её желательно предусмотреть с самого начал.
123: И причём исполнитель, являясь сторонней организацией, он чужак на предприятии, и он воспринимает, воспринимается сотрудниками как источник всех бед. Они жили спокойно, хорошо, тут пришли какие-то люди, им пытаются
124: Рассказать про новую систему, а им было хорошо и в старой. Вот, и, соответственно, должна быть совместная работа группа управления проектом со стороны заказчика, со стороны исполнителя для исправления этой ситуации.
125: Так, теперь рассмотрим причины риска, какие предполагаются проблемы. Ну и, соответственно, рассмотрим, какие решения могут мы предлагаем. Итак, сотрудники заносят данные только в старую систему, игнорируя работы в новой системе.
126: Это проблема, которая у нас возникает. Это задержка сроков реализации проекта вплоть до его полной остановки. Вот.
127: 2 проблема это то, что при частичном вводе информации у нас нет возможности оценить комплексную работоспособность всей системы. Вот корректность взаимосвязи информации по разным учётным блокам. То есть, если 1 подразделение оперативно вносит информацию, 2 задерживает, то корре,
128: Картины мы в системе не увидим и, соответственно, не сможем для себя понять, насколько данные, которые она выдаёт, устроят заказчика. Вот.
129: Какие быть подходы к решению о том, что так
130: Заказчик ещё до начала работ должен донести до всех участников процесса информацию о важности этой работы, вот однозначности принятого решения о том, что система будет внедряться, она будет жить, вот донести сроки выполнения работ. Вот.
131: Эта информация должна быть поддержана как личным настроем руководства и ответственных лиц, так и с юридической стороны. Вот, то есть это должны быть выпущены или приказы о назначении распоряжения по предприятию, прочие документы, которые приняты на
132: Предприятия. В зависимости от внутрифирменных правил до сотрудников предприятия должен быть доведён перечень работ со сроками и критериями, по которым будет осуществляться проверка их работы. Вот здесь очень важное слово. Это критерий. Обратите на него внимание.
133: Оно чаще часто будет дальше встречаться в докладе, потому что что такое критерий, он определяет именно правила проверки, конкретизирует результат, который должен быть достигнут пользователем. Вот.
134: Используемые критерии должны быть точно и полно описаны, потому что с их помощью пользователи могут посмотреть на результат, который должен быть в итоге получен, и её как бы увидеть промежуточные шаги, кото
135: Мы должны сделать для его достижения. Вот.
136: Следующее решение, это должны быть разработаны стимулирующие, мотивирующие факторы, которые заставили бы сотрудников начать работу в новой системе. Вот в качестве примера мы можем вспомнить проект, где в качестве поощрения
137: Сотрудникам была выписана как бы обещана и выполнена поездка на курорт. Вот, может быть, на предприятии разработаны кипиай, система премий и система штрафов. Но надо учитывать, что при отрицательной мотивации, как система штрафов, она работает
138: Только в купе с положительной. Вот сотрудники, которые активно участвуют в проекте, могут получить отгулы за сверхуроч, ну как бы оплату за сверхурочные работы и прочие системы мотивации, которые приняты на предприятии.
139: Вот со стороны исполнителя также должны быть выделены ответственные лица, которые отвечают за прогресс по наполнению данными новой системы. Прогресс контролируется по тем критериям, которые доведены до пользователей. Вот, то есть работы они ставят
140: Перед исполнителем и контролиру, перед исполнителем и как бы заказчиком и контролируется по 1 критериям. То есть у нас нету разницы между тем, что мы сказали пользователю сделать и как мы его будем проверять, все должно быть.
141: Единообразно. Вот также в функции этих сотрудников входит контроль за
142: Контроль за исполнением сотрудники предприятия поставленных ими задач, то есть команда со стороны исполнителя, контролирует исполнение задач команды со стороны заказчика. Вот производится анализ причин отставания, определяется необхо.
143: Необходимая помощь консультации на ранних этапах проекта проверка может осуществляться несколько раз за день для того, чтобы нам действительно убедиться, что люди впустую, что люди работают и не работают впустую. Вот на более поздних этапах интервалы проверок можно увеличить.
144: Вот причина отставания выносится на рабочую группу проекта и принимается решение. Если отставание не может быть устранено при ручной работе, там, допустим, даже сверхурочно, то можно рассмотреть техническое решение вопроса. То есть это автомати.
145: Перенос может быть улучшить интерфейс, ну, подключение других там групп людей.
146: 2 причина риска это работа в новой системе не спланирована со стороны заказчика.
147: Что мы, какие проблемы получаем в этом случае сотрудники не знают, какие конкретные задачи, которые они должны решить и в какой срок. Вот, то есть контроль прогресса проекта осуществляется по крупным вехам и, соответственно, проблема отставания фиксируется. Слишко.
148: Поздно. То есть, когда мы должны уже получить результат, мы понимаем, что данные никто не вносил.
149: Соответственно, это возникает, приводит к спешке возникновению работы во внерабочее время. Эта спешка, когда надо срочно предоставить информацию к критической дате, как следствие, приводит к низкому
150: Качество информации вот так как проверить некогда к переделкам, к исправлениям, увеличению сроков.
151: Вот какие мы видим возможные подходы к решению вот со стороны заказчика для всех участников проекта должен быть составлен план, график работ. Вот
152: Для всех, для всех своих сотрудников, с учётом отпусков, праздников, командировок, времени на подготовку данных. Вот проведение инвентаризации и прочих временных отклонений, которые могут возникать. У нас был отрицательный пример на 1 из проекто.
153: Когда был составлен план, график проведения работ по запуску системы, в котором не был учтён корпоративный отпуск. Вот, то есть отпуск нельзя было отменить, он идёт строго по графику, но ложится на запуск. При этом
154: График заказчиком был согласован, но физически он не мог быть исполнен, потому что люди на предприятии отсутствовали.
155: Так, следующее решение это исполнитель должен сопоставить план, график заказчика со своим перечнем работ и обеспечить синхронное выполнение, выделение своих ресурсов для обеспечения поддержки, то есть исполнитель должен
156: Запланировать свои ресурсы, чтобы команды работали синхронно, и пользователи оперативно получали ответы на свои запросы, чтобы не происходило подвисания, потому что это тоже демотивирует персонал. Если они не могут вовремя получить ответ на свой вопрос, они откладывают на потом, ну и соответствен
157: Приводит к задержкам. Вот план должен содержать конкретные точки, в которых проводится анализ достигнутого результата. Вот, то есть анализируется процент. Допустим, можно проводить анализ процента внесённой информации. Сколько процентов к определённой дате должно
158: Внесено вот регулярное проведение статус собраний, на которых команда проекта осуществляет контроль за соблюдением плана графика, анализирует возникающие проблемы, готовит пути решения, смотрит прогресс проекта при изменении сроков план график должен быть актуализирован с обеих сторон.
159: Переходим к следующей причине риска. Это то, что в проект была заложена более глубокая детализация данных в системе. Вот это может принести следующие проблемы, что долгий срок ввода информации, отставание по вводу по проверке данных. Вот, то есть, соответственно,
160: Это будет вызывать переработки, недовольство сотрудников, низкое качество информации, так как регистрация и проверка данных делается в спешке, какие мы видим возможные подходы к решению.
161: Решение данной ситуации можно осуществлять как с организационной стороны, так и с технической. Вот организационное решение со стороны заказчика может быть следующее, то есть сократить объём вводимой информации, оставить ту, которая действительно нужна. То есть ещё
162: Взглянуть на ту детальность, которая была заложена в проект. Вот можно рассмотреть возможность увеличения количества пользователей для ввода информации может быть разово, то есть привлечь какие-то дополнительные группы людей, которые позволят нормализовать работу в системе.
163: Допустим, на время двойного ввода, потом
164: Пользователи справятся с этим объёмом после того, как двойной ввод будет завершён. Распределить ввод информации между различными подразделениями предприятия, увеличить количество пользователей, сократив нагрузку на конкретную группу пользователей. Вот.
165: В качестве примера можно привести, вот информация, допустим, о производственных операциях, перенести с текущего места на, на места, где производится учёт этих операций. То есть очень часто мы можем столкнуться с ситуацией, что есть экономически
166: Цех, который собирает бумажки по операциям, которые были сделаны, передаёт их, допустим, бухгалтерии. Бухгалтерия вводит эти данные. Давайте поставим, организуем рабочее место экономиста цеха, чтобы он сам вводил эти операции.
167: Также можно рассмотреть пример по детализированному учёту спецодежды до конкретного получателя. То есть если эта работа повесить на бухгалтера, то его объём увеличится в разы, потому что ему надо будет фиксировать каждое физическое лицо.
168: Ту, которую получила спецодежду. Вот если раньше он фиксировал выдаче спецодежды на подразделение, но в подразделении учёт по физлицам все равно ведётся. Так, давайте поставим, организуем рабочее место начальника участка, который будет вести
169: Учёт по физическим лицам, спецодежда в подразделении. То есть мы тем самым улучшим его, как бы ему придётся вести этот учёт не на бумажках, а в системе, что сократит его время на обработку информации.
170: Технические решения, данной как бы
171: По данной проблеме это может быть увеличение скорости ввода информации за счёт проработки эргономики, рабочего места, создания средств автозаполнения. Вот создание специализированных арм.
172: Можно рассмотреть механизм использования вводов на основании вот для этого может потребоваться подключение дополнительных подразделений, ну, для ввода первичных документов, оснований. Вот, например, если у нас бухгалтерия приходовала раньше
173: Самостоятельно материалы, которые поступили, то мы можем организовать рабочее место на в отделе закупок, который будет формировать заказ поставщику. Вот бухгалтер уже на основании этого заказа будет вводить непосредственно
174: Соответственно, документ поступления, проверяя, что номенклатурная позиция указана корректно и, соответственно, ну, как бы указывая фактическое количество поступления. Вот.
175: То есть бухгалтер будет только, скажем так, контролировать, а не вводить самостоятельно. Также можно организовать автоматическое составление документов путём интеграции с оборудованием или с другими системами. Ну, на своих проектах. Мы вот на 1
176: Лесоперерабатывающих Заводов выполняли интеграцию системы, систему управления по распиловке брёвен. Вот, то есть полученные данные формировали документы по выпуску продукции с хорошей детализацией. То есть мы
177: Указывали каждую пачку полученных лесоматериалов в пачке указывали размер, количество досок, много много разных параметров, которые не вводились пользователем вручную они брались с оборудования с каждой производственной операции распиловка, сушка.
178: Хранение. Вот. И также примерами сокращения времени выполнения процесса можно считать 3 использование штрихкодирования, которое можно применить к документам для быстрого поиска документа. Вот к товарам, к
179: Операция, то есть отсканировали операцию, считаем, что она начата, отсканировали её 2 раз. Считаем, что она завершена. Вот, вот, если рабочее место будет автоматизировано. Ну то есть оператор может
180: Ну, с минимальными трудозатратами отчитаться о том, что он, то есть сколько времени он выполнял ту или иную операцию, какую операцию в конечном итоге завершился рабочий день. Вот. Ну и так.
181: Дополнительно можно взять средства загрузки данных из внешних источников. Это из эксель, из системы электронного документооборота.
182: Следующая причина риска, которая, может быть, это работники не уделяют времени проверке данных, внесённых автоматически, что это то есть данные внесены автоматически, это чаще.
183: Всего данные, которые мы либо занесли как ввод начальных остатков, загруженный с прежней системы, либо это интеграция с предыдущими системами, либо перенос данных из других систем как внешних источников данных. Вот.
184: Какие предполагаемые проблемы у нас могут быть? Ну, 1, это самое очевидное, это некорректная справочная информация и остатки вот то, что
185: Данных идёт не оперативно, а с неким запозданием. Это приводит к тому, что ошибки, которые могут возникать при обмене, выявляются поздно. То есть иногда это уже на этапе закрытия периода. Вот.
186: Соответственно, система долгое время работала без проверки могли появиться дубли из справочников, дубли документов, документы с неверными цифрами, с некорректным заполнением вот это, может быть, возникало из за скрытых оши.
187: Которые невозможно было выявить на этапе тестирования, потому что предугадать все действия пользователей не на этапе тестирования нельзя. Вот.
188: А может быть, из за некорректно дела действий пользователя непосредственно при вводе документов, но выявляется это только на конечном этапе, когда мы пытаемся закрыть период. Вот.
189: И, соответственно, это надо предпринимать действия по срочному исправлению, то есть по срочному до обучению пользователей, по срочной правки там системы обмена для того, чтобы устранить
190: Проблема, которую мы зафиксировали уже за целый месяц. Так, ещё предполагаемая проблема, это ошибки обмена, которые поздно выявляются, приводят к необходимости перезагрузки, перезагрузки информации. Вот недостоверные данные системы, которые могут быть
191: Использованы в других учётных блоках. Ну то есть мы приняли в 1 месте, передали в другой, и там тоже информация исказилась.
192: Вот, и это. А если вы ввели, допустим, неверные, неверно начальные остатки, то правка ранее введённых документов для корре, для корректной аналитики, при изменении автоматически внесённых остатков прочих данных, то есть надо будет вносить, изменять до
193: Документы задним числом, и все это приводит к тому, что у нас в системе возникает грязная справочная информация, которую тоже придётся чистить, то есть на этом этапе, отказавшись от
194: Своевременной проверки данных мы приобрели большой большой пул проблем, который тоже требуется решать.
195: Итак, это решение проблемы. Так, проблема эта схожа с проблемой игнорирования ввода данных в новую систему. Вот она отличается только тем, что данные, которые появляются в системе автоматически, сотрудники заказчики чаще всего относятся к название.
196: Ответственности исполнителя. Вот, и сотрудники заказчика считают, что не нужным проверять, контролировать. Хотя в систему загружаются данные, которые подготовил непосредственно сам заказчик, а исполнитель проводит только техническую сверку. Ну, допустим, по количеств.
197: Документов, которые пришли там по
198: По тому, что информация появилась в необходимых разделах. Вот, и если пользователь в первичной системе допустит ошибку, она перейдёт в новую систему и может привести к непрогнозируемым действиям. Вот.
199: Так, при разработке кода обычно прорабатывают только корректный ввод документов. То, что пользователь может наделать, предусмотреть невозможно. Вот, соответственно, решение, то есть, может быть, как со стороны заказчика, так со стороны исполнителя.
200: Со стороны заказчика должны быть выделены сотрудники для проверки данных, внесённых автоматически, ввод начальных остатков. Ну, сотрудники для проверки, ввод начальных остатков проверки для документов, которые появляются в результате обмена с другими
201: Система, вот, и до сотрудников должен быть доведён перечень работ, которые они должны проделать при проверке со сроками и с критериями проверки. Вот эти критерии также будут контролироваться исполнителем.
202: По тому, как качественно сотрудники заказчика проверили информацию, вот со стороны исполнителя должен быть выделены ответственные лица, которые отвечают за прогресс по наполнению данными в системе.
203: Начальным остаткам, по данным по интеграции с иными системами, прогресс контролируется по тем же критериям, которые не до пользователей, также пользователи должны осуществлять контроль за исполне за исполнением сотрудникам предприятия поставленных ими задач.
204: Анализировать причины отставания, осуществлять помощь консультации. Процесс прогресса осуществляется по количеству проверенной информации. Ну то есть за сколько там введены данные за день, за месяц по определённым счетам учёта, по опреде.
205: Следующие риски, они связаны уже непосредственно с подготовкой проекта к запуску. Вот при, когда мы готовим проект к запуску
206: Мы можем столкнуться с риском о том, что пользователи игнорируют работы по подготовке справочной информации. Вот успех проекта очень сильно зависит от качества нси. Перед началом работы необходимо подготовить информацию.
207: Ну, о тех справочниках, которые используют, то есть какие на предприятии используются статьи затрат или планируются использовать прочие доходы, расходы, статьи, движения денежных средств. Необходимо преобразовать справочники, номенклатуры, контрагентов, договоров, исходя
208: И из концепции внедряемой системы, и исходя из той аналитики, которой сейчас не хватает для анализа деятельности предприятия. Если данные работы не будут выполнены при подготовке запуску, то произойдёт затягивание сроков проекта. Цели проекта не будут до
209: Достигнуты. Вот. И чистку информации все равно придётся проводить, но её придётся проводить уже в новой системе с корректировкой, ну, с возможной корректировкой ранее введённых документов мы получаем двойную работу.
210: И этот риск часто провоцируется тем, что сотрудники заказчика не видят необходимости работать с нси, которая переходит в новую систему они считают, что если в прежней системе можно было работать с ней, то и в новой получит.
211: Системе получится она же, ну сейчас же они как-то справляются. Вот. И то есть, так как требования к качеству новой си определяется исполнителем. Очень часто сотрудники заказчика считают
212: Подготовка справочной информации для новой системы считается задачей исполнителя. Мы вам передадим систему, изберите из неё, что вам необходимо. Вот со стороны исполнителя также бывает, что заказчика не требуется нормализованная справочная информация для ввода новой системы. Вот.
213: Ну, считается, что заказчик предоставил, с тем мы будем работать.
214: На своих проектах мы всегда проговариваем вопрос нормализации нси. Вот в сложных ситуациях даже открывается специальные проекты по нормализации нси, по приведению, ну, это касается предприятий, которые имеют большой
215: Количество, допустим, номенклатурных позиций, большое количество контрагентов, договоров, вот, вот, ну, допустим, на тех же самых работах, на предприятиях, связанных с лесопереработкой, мы, со своей стороны, участвовали в работах по нормали,
216: Справочник контрагентов, договоров, физических лиц, статей, движения денежных средств. То есть приводили к единому классификатору, который был, ну, создан в системе мдм. Вот эти работы.
217: Проводились использование таблиц, куда данные выгружались. Вот они сопоставлялись с таблицами текущих данных в системах проводилось заполнение необходимых кодов, данные состыковывались и после того,
218: Они были нормализованы, эти данные подгружали в систему универсальными обработками загрузки из табличного документа.
219: Таким образом, запуск системы уже проводился нормализованной информации, и нам не приходилось перелопачивать все данные в системе. То есть эти, да, эти работы были проведены во всех таблицах. Итак,
220: Какое возражение, если в прежней системе можно было работать с и то и в новой получится. То есть, ну и мы предполагаем следующую проблему о том, что мы перенесём мусор исторических систем в новые, то есть будут дублирующие элементы лишние.
221: Элементы, которые не используются в настоящий момент. Вот, то есть будет отсутствовать нормализо, как бы нормализованные, уникальные признаки идентификации справочной информации. Вот, а это, в свою очередь, может привести к про
222: При обмене данными вот, то есть при обмене может быть не поддержана целостность систем, ну там при обмене с другими системами. Вот, то есть, если у нас дубли
223: Контрагентов будут иметь одинаковый код, то, соответственно, при переносе остатков, то они будут, могут быть суммированы или, наоборот, размножены. Ну то есть при
224: Интеграции с другими системами может принести, привести к тому, что в этой системе эти контрагенты также могут быть задублированы. Соответственно, вот эта грязная информация понесётся дальше. Вот, ну, это может привести также к тому, что будет отсутствовать возможность строить управле.
225: Отчётность с необходимой аналитикой, которая требовалась в проектах, потому что её никто не занёс в справочную информацию. Вот, и как результат, цели проекта не будут достигнуты. Вот, и после внедрения потребуется работы по приведению
226: Необходимому ввиду для того, чтобы получать эту отчётность.
227: Итак, какие мы видим возможные подходы к решению со стороны заказчика должны быть выделены ответственные лица, которые будут отвечать за нормализацию си, должны быть определён перечень работ по нормализации требования к результату и критерии приёмки.
228: Вот на своих проектах мы используем стандартный реестр требований к си, который уточняется, исходя из специфики заказчика. Вот нормализованная си должна отвечать требованиям новой концепции, обладать уникальными признаками идентификаторами.
229: Должна быть доведена важность работ, которые они проделывают, и разработана соответствующая мотивация.
230: Так, следующее возражение, которое мы разбираем, это подготовка справочной информации для новой системы, задачи исполнителя. Вот сотрудники заказчика, то есть
231: Не участвуют в работах по созданию, по созданию нормализации проверки новой и, а сотрудники исполнители могут не до конца осознавать специфику бизнеса. Это может привести к некорректной нормализации. Ну, например, если мы возьмём, ну, как бы
232: Стандартный справочник. Мы можем увидеть в нём элементы гайка м 4, м, 4, ghost м 4 оцинкованная м 4 жёлтая вот и.
233: Эти позиции, то есть можно воспринимать и как 4 уникальные позиции, или как 1 позицию, которую необходимо свернуть, и только сотрудники, работающие с конструкторской документацией, знают, что является добрым, а что является уникальным элементом очень час.
234: Эта номенклатура, ну, как бы называлась на предприятии, так как она предоставлена в прайсах поставщиков, в документах, которые приходят поставщиков. Вот, и именно специфика бизнеса определяет, как оформляется конструк конструктор.
235: Документация, насколько тот или иной параметр номенклатуры, который указан в наименовании, важен для производства или для продажи, может повлиять на цену продажи, на использование спецификации. Вот исполнитель, который делает проект, ну,
236: Совместно с заказчиком не всегда может знать об этих цепочках, не всегда может знать об уникальных признаках номенклатуры, которые важны. Вот.
237: Ну и, соответственно, возможный подход к решению, это исполнитель прорабатывает требования и определяет концепцию, вот определяет критерии поиска проблемных позиций, правила нормализации, при необходимости разрабатывает обработки для нормализации данных, как в системе или во внешних
238: Источников. Вот заказчик согласует эти правила нормализации, осуществляет проверку работ исполнителя, проводит работы по ручной нормализации, если они необходимы. Вот. И крайне желательно, чтобы справочную информацию, которую мы предполагаем грузить в новую систему.
239: Её можно было бы посмотреть предварительно в виде таблиц, ну, скажем, эксель файлов. Вот это позволит в большей степени вероятности проконтролировать корректность преобразования переноса и посмотреть, что все необходимые аналитики заполнены там методом.
240: Сводных таблиц, поискать дубли. Вот, и в своих проектах мы осуществляем проверку, выгрузку данных в эксель преобразование нси заказчик при помощи обработок. То есть эта работа проводится для того, чтобы нси
241: Перенеслась в новую систему уже в корректном виде.
242: Секундочку, гляну чат.
243: Все. Итак, следующий риск, который мы связан с подготовкой системы к запуску, это необходимо внести большой объём справочной информации, начальных остатков для начала функционирования системы. Вот.
244: Что у нас может вызвать эту как бы этот риск. Вот с 1 стороны, это очень похоже с предыдущим риском. Вот. То есть сотрудники полагают, что остатки в прежней системе есть, и поэтому
245: Их надо просто взять и перенести. Дополнительных преобразований не требуется, а все сложности с переносом должен решить исполнитель. Вот, а если переносом занимается исполнитель непосредственно, то он отвечает полностью за перенос, то есть забрать данные из предыдущей системы.
246: Трансформировать их в необходимый вид и внести в новую систему. Вот иногда кажется, что перенос остатков это не сложная работа. Вот сотрудники все могут забить руками.
247: Вот и ничего сложного в этом нет.
248: Вот, и со стороны исполнителей также иногда бытует мнение, что заказчик предоставил для переноса, то и будет внесено, ну то есть дополнительные проверки качества данных предоставленных данных не делается или используются типовые обработки, перенос, которые взяли все, что было и перенесли.
249: Вот. Соответственно, получается, что контроль качества предоставленной информации будет осуществляться только на этапе ввода в систему документа. Ввод начальных остатков. То есть мы контролируем, он провёлся или не провёлся. Если не провёлся, тогда начинаем искать ошибки. Вот и все эти подхо
250: Не учитывать, что если как бы внесённые начальные остатки будут некорректны.
251: Или данные старой системы, из которой делался автоматический перенос, будут неверными, то приведение информации к нужному ввиду потребует дополнительного времени и ресурсов на, ну что увеличит длительность, стоимость и стоимость проекта. Вот, то есть
252: Почему информация о может быть неверна? Ну, потому что бухгалтер взяла, посмотрел по, по осв, по верхнему уровню на уровне контрагента, что взаиморасчёты у неё все более менее корректные. А если сделать детализацию договоров, то мы можем увидеть уже накопленные ошибки за
253: Предыдущих периода тоже самое, когда мы смотрим на остатки. То есть глядя на на 1, на 1 из уровней детализации, мы видим только 1 картину, а при переносе используются данные других как бы источников.
254: Другие другие источники данных, допустим, те же самые учётные регистры, где детализация информации будет иной и могут содержаться ошибки. Вот мы всегда в своих проектах обращаем внимание на этот аспект, выдвигаем требования по качеству и качеству данных об остатках
255: Вот, то есть у нас даже разработана специальная система отчётов, которая произво проверить позволяет проверить исходные данные по ряду критериев. Соответственно, зафиксировать ошибки. Эти ошибки соотве донести до заказчика для исправления.
256: Итак, разберём возражения, и какие проблемы они нам несут. Так, возражения, остатки из прежней системы. Их необходимо просто взять и перенести.
257: Так, к чему это может привести? Остатки? Ну, во первых, остатки в разных видах учёта. Управленческий учёт, бухгалтерский учёт. Налоговый учёт могут отличаться. Вот. И при переносе надо будет проводить приведение остатков к единой цифре.
258: Вот, то есть надо определить, какие данные необходимо взять за основу и как трансформировать данные для приведения их к этой единой цифре. Ошибочные данные об остатках, то есть могут содержаться отрицательные суммы.
259: Количество, то есть может быть количество без суммового остатка или может быть
260: А сумма без количества, то есть, опять же, я уже как говорил, то, что это может быть на разных уровнях аналитики возникать такие ошибки. Вот очень часто, ну, то есть в системе, допустим, упп,
261: Который осуществляется переход на систему ерпи. Аналитика регламентированного учёта может не совпадать с налитиков управленческого учёта. В регламентированном учёте мы видим остатки, скажем так, по счёту учёта номенклатуры, складу, а по управленческому учёту они будут вестись по номенклатуре серии.
262: Складу. Ну вот, то есть с более глубокой детализацией. Если проведены работы по нормализации справочников, то требуется перенос остатков на новые нормализованные позиции, которые были внесены в систему приёмник, то есть
263: Номенклатура должна иметь в старой системе код нормализации, на который будут переноситься остатки.
264: Так какие мы видим подходы к решению? Вот со стороны заказчика должны быть выделены ответственные лица, отвечающие за контроль переносы си перед переносом. Необходимо проверить качество информации в базе. Источники. Проверка осуществляется по согласованным критериям. Ну, как я уже сказал, что
265: Мы их можем предоставить. Вот её могут проводить как сотрудники заказчика, так сотрудники исполнителя в случае возникновения отклонений принимается решение о способе исправления. То есть он может быть автоматическим при переносе или ручной в базе источники.
266: Правки данных. Ну вот, то есть проверка может осуществляться либо стандартными отчётами, либо специализированным созданными отчётами. Ну, это зависит от того, какая, какая глубина аналитики будет анализироваться, какие есть отчёты станда.
267: Отчёт в системе, вот, потому что, ну вот мы, то есть большие предприятия, допустим, холдинги для сокращения времени закрытия, они имеют набор проверочных отчётов, которые запускаются перед процедурой закрытия месяца, перед
268: Процедура расчёта себестоимости. И если эта система отчётности, даже иногда она запускается автоматически, ошибки приходят на электронную почту, и ответственные лица должны их исправить. То есть, когда приступает к закрытию месяца, то есть уже оши.
269: Система не содержит. Вот. Ну, поэтому, если эти отчёты есть, они просто прогоняются, проверяются, что вся там остатки находятся в нормальном состоянии, и, соответственно, их можно переносить. Вот.
270: Ну, соответственно, и также система проверки зависит от источника переноса данных. То есть, если мы будем переносить с бухгалтерских данных, то достаточно проанализировать оборотные ведомости с разворотом по всем аналитикам. Вот, а если мы будем переносить данные со смешанных источников,
271: Ну, допустим, часть данных с управленческого учёта, извините, часть данных с бухгалтерского учёта, и эти данные должны быть между собой, ну, как бы трансформированы. Вот, то отчётность лучше создать, вот, чтобы в 1 отчёте могли
272: Увидеть, ну, сопоставить данные с разных источников, ну, и, соответственно, их проверить. Вот в своих проектах мы отчёт для проверки создаём, и они показывают возможные ошибки данных, которые есть. Вот, исходя из типа ошибки уже
273: Принимается решение по правилам исправления. Вот, допустим, у нас есть развёрнутое сальдо по документам расчётов на, на, допустим, на счетах взаиморасчётов.
274: Вот, то есть, ну, как бы, имея там счёт расчётов с поставщиком, мы видим в разрезе документов, расчётов сальдо, как по дебету, так по кредиту его можно свернуть автоматически. То есть мы берём остаток и распределяем его по фифу, по
275: Последним документам расчётов, которые были зарегистрированы по данному поставщику, вот это исправление и автоматическое исправление переноса.
276: Ну, сворачивание, конечно, проводится в рамках 1 договора.
277: Вот, а если мы видим о том, что у нас по 1 договору задолженность, скажем так, по счёту, ну, с поставщиком отрицательная, а по другому по счёту расчет с поставщиком положительная, то вот здесь уже автоматическое, как бы, сворачивание ниже.
278: Желательно, потому что необходимо проверить, почему по 1 из договоров возникла переплата, и перебросить эту сумму уже вручную, выполнив операцию. Корректировка долга, то есть, пере, ну, перекинуть задолженность либо на аванс, либо её перекинуть на другой договор.
279: Если это, ну, предполагается, вот, вот, в случае, если данные в разных видах учёта имеют отклонения, то принимается решение, откуда эти данные лучше взять. Вот.
280: Ну, оптимально проведение инвентаризации перед началом переноса остатков, вот, и путём регистрации результатов в системе источника осуществ, избежение данных в разных видах учёта. Ну, чтобы мы чётко были убеждены о том, что данные у нас в управленческом, бухгалтерском и налоговом учёт
281: Одинаковые и в разрезе всей аналитики. Вот.
282: Бывает ошибка о том, что у нас есть 0 остаток по номенклатуре, но, но при детализации, допустим, данных до серии номенклатурных позиций мы видим положительные отрицательные остатки. Ну понятно, что это возникло давно. Сейчас разбираться с этим уже бесполезно.
283: Ну, так как остаток по номенклатуре 0, то мы можем это поправить и при переносе автоматически. Вот. Но если остаток не 0, есть серии с положительным отрицательным остатком, то, конечно, только инвентаризация может выявить какая
284: Серия осталась. Вот, ну то есть можно проработать правила трансформации данных, трансформации остатков для каждого вида учёта, исходя из тех аналитик, которые будут востребованы, то есть придумать, как разделить
285: Остатки управленческого учёта по, на по аналитикам бухгалтерского учёта, ну как, допустим, если берём опп, как номенклатуру, характеристику, серию, склад должны попасть на аналитику бухгалтерского учёта. Это счёт, номенклатура, склад. Вот, то есть
286: Счёт можно установить, исходя, допустим, из неких признаков номенклатурной позиции или счёт исходить исходя из склада. Вот. Но иногда эта автоматическая трансформация, она невозможна, вот. И надо как-то действительно проводить инвентаризацию и смотреть её результат.
287: Вот можно проработать правила преобразования текущей позиции на нормализованные позиции, вот как частный случай нормализации позиции должны иметь код, ну, как я уже говорил ранее, на который они должны быть попасть в новой системе, то есть в старой системе для каждого
288: Контрагента договора номенклатурной позиции вносится код новой системы и при переносе остатков. То есть уже остатки выводятся в рамках этого кода, то есть в рамках новых элементов. Вот по возможности результаты лучше выгрузить.
289: После всех преобразований распределений в эксель файл вот для проверки корректности полученного результата.
290: Итак, следующее возражение. Если переносом занимается исполнитель, то он полностью отвечает за перенос. Вот какие проблемы мы видим. То есть сотрудники исполнителя могут не до конца знать структуру хранения данных об остатках в системе. Вот, ну,
291: Потому что система может быть доработана, могут, там в ней внесена дополнительная справочная информация. То есть дополнительный регистр сведений исполнитель об этом не может знать. Вот, и документация, то есть как бы
292: Для полного знакомства со структурой хранения данных заказчик должен предоставить исполнителю полное описание, но его чаще всего нет. Или оно неактуально. Вот и нюансы отклонения, то есть по аналитикам, где они смотрят, какие
293: Какие отчёты они смотрят, знают сотрудники заказчика, вот, которые или поддерживают систему, или которые работают в ней. Вот. И также сотрудники исполнителя могут не обладать необходимыми знаниями по как бы
294: По той системе, в которой хранятся остатки. Вот, потому что в команду исполнителя включены специалисты по 1 с, вот специалисты по другим как бы, системам, ну, по другим системам хранения данных, там по эскелю они подключаются.
295: Только по мере необходимости. Вот это, конечно же, влияет, в свою очередь, на сроки проекта, на стоимость, потому что этих сотрудников надо найти, включить в команду проекта. Вот. Ну и, конечно, быстрее и дешевле использовать сотрудников.
296: Заказчика для выполнения этих работ.
297: Итак, какие мы видим возможные подходы к решению? Вот, ну, исполнитель прорабатывает требования к остаткам. С какой детализацией вот они должны быть предоставлены? Прорабатывает требования к порядку проверки.
298: Порядку внесения в новую систему. Критерии поиска нормализованных позиций при необходимости разрабатываются обработки для загрузки, для загрузки данных. Вот загрузка данных может происходить как непосредственно из базы.
299: Источника данных так промежуточных файлов. Допустим, эксель. Вот если загрузка происходит с промежуточных файлов, то их готовят сотрудники заказчика. Сотрудники исполнителя могут только помогать консультировать. Вот выгрузка происходит согласованный шаблон, который имеет все
300: Необходимые данные по аналитика. Вот первичную выгрузку может, конечно, подготовить исполнитель. Ну, как я уже сказал, что при привлечении тех сотрудников, но обогащение и исправление данных осуществляет только заказчик после переноса данных.
301: Сотрудники заказчика исполнителя совместно осуществляют проверку полученного результата.
302: Так, следующее возражение, которое у нас есть, это сотрудники с забьют руками начальные остатки, и ничего сложного в этом нет. Ну, это предполагаемая проблема. То есть большой объём данных для ввода, большие потребности в ресурсах, долгий срок ввода информации.
303: Вот, надо понимать о том, что иногда приходится несколько раз вносить данные, ну, допустим, на в начале проекта мы вносим данные о количестве материалов, которые есть на складах, а после того, как
304: В системе источники произведут расчет себестоимости. Мы вносим данные о сумме, которая сформировалась по итогам закрытия месяца. Вот. Или данные в 1 системе были пересчитаны, исправлены и их надо будет перебить. Вот.
305: Автоматически, когда идёт перенос данных, это, конечно, запускается обработка выгрузки, загрузки вручную. Это, конечно, время. Вот ошибки при вводе данных вручную могут возникать из за некорректности первичных данных. Ну, потому что
306: Просто человеческий фактор, человек может ошибиться, то есть ручное преобразование данных. То есть если мы при вводе остатков пытаемся ещё сделать какие-то расчёты преобразования, то, конечно же, это может повлечь ошибку. Вот, ну и ошибки также.
307: Возникает при ручном вводе из за перехода на нормализованные справочники. То есть нам надо видеть не просто элемент, который написан, надо ещё понимать, на какой новый код, на какой новый элемент справочника должен быть отнесён.
308: Какие у нас есть возможные подходы к решению? То есть это выделение отдельной группы лиц, которые будут заниматься ручным переносом остатков и сроки проведения работ, критерии проверки. Провести обучение данных сотрудников. Вот можно подго.
309: Промежуточный файл, в которые будет осуществлён ввод информации в них при помощи формы приобрести необходимое образование по исправлению ошибок по нормализации. Вот критерии проверки данных полученных файлов, вот исполнитель.
310: Универсальными обработками по загрузке данных из табличных документов, которые были подготовлены заказчиком, может произвести загрузку данных для ускорения ввода информации и повышения качества данных. Очень часто упомина,
311: Как, ну вот в докладе, это как обработки универсальной обработки, загрузки данных. Они, в общем то, есть, на, думаю, в свободном доступе на дисках ттс, которые позволяют данные из эксель таблиц занести в систему 1 с, вот.
312: И переходим к заключительному риску, который хотелось бы рассмотреть в данном вебинаре. Вот этот риск у нас административного характера, это отсутствие своевременного согласования, утверждения, подписания документов, которые сопровождаются проект. Вот
313: Под согласованием мы здесь понимаем приёмку итоговой версии документа. Вот. И, собственно, подписание документа это ответственно, по каким причинам мы можем отследить появление данного риска. Так, ну 1 причина
314: 1 признак это сроки согласования с заказчиком выходной до проектной документации выше, чем сроки, указанные в плане графике договора.
315: Вот, или сотрудники заказчика осуществляют долгую реакцию на текущие запросы исполнителя в ходе выполнения работ по проекту. То есть мы, когда обговаривали, первоначально, думали, что ответ на запрос
316: Будет получен в течение там 1 дня. А получается, что вопрос подвисает неделю, а то и 2. Вот. И то есть, как мы видим, основной признак это несоблюдение установленных сроков со стороны заказчика. Очень часто при заключении договора заказчик хочет получить результаты в очень
317: Сжатые сроки. Вот исходя из его пожеланий, в договор включается минимально допустимое время на согласование, на предоставление ответа. Вот.
318: Но структура согласовательного процесса предприятия может быть такой, что заявленный срок не будет выдержан. В этом случае решение 1. Надо пересмотреть план, график, включить в него те сроки, которые реальны для предприятия. Вот, но часто бывают и другие.
319: Причины, которые мы сейчас разберём. Итак, сроки согласования с заказчиком выходной документации выше, чем срок, указанный в плане график договора, может быть, потому, что в проект заложили большой объём документации.
320: Вот, то есть этот объём избыточен для предприятия. Ну, предприятие, когда заключает договор, оно считает, что если создать много, много документов, и они
321: Будут содержать все, все подробное описание, то это будет благо. На самом деле это не всегда хорошо, потому что, во первых, эту документацию надо будет прочитать, согласовать. Во вторых, эту документацию надо будет поддерживать в актуальном состоянии. Вот, и
322: Вот по опыту могу сказать, что когда документация очень, очень подробная, очень, очень детальная, она перестаёт быть актуальной буквально через год после окончания проекта, потому что сам заказчик не может её поддерживать постоянно.
323: Актуальном состоянии. Это требует слишком больших затрат. Вот следующая проблема, которая может вызывать риск. Это формат документации проекта сложен для восприятия, для восприятия, при лицам, которые принимают эту доку.
324: Ну, например, методы описания бизнес процессов, заложенные, ну, заложены схематически. Вот, д сппр, вот, но ты, которые принимают документ, тяжело работать со схемами, им более привычно и понятно, текстовое описание.
325: Таблицы, вот к согласованию документов могут привлекаться лица, которые не участвовали в процессе их как бы, предварительной подготовки. То есть они не участвовали в пред, ну, как бы, в
326: Предварительных процессах, которые привели к подготовке этих документов. Вот не относятся напрямую к процессу. Соответственно, у них возникает очень много вопросов, что очень сильно затягивает процесс согласования. Вот они учли,
327: То, что сотрудники заказчика на момент начала проекта имели высокую загрузку, и, соответственно, они не могли посвятить время проекту, то, которое изначально планировалось.
328: Вот. Также может это возникать из за того, что у заказчика отсутствует схема прохо прохождения согласования документов. Вот документ просто может. То есть, ну, нет системы электронного документооборота и документ, может быть, нет системы оповещений, документ может просто зависнуть.
329: Вот, а согласовать, то есть на неком этапе человек, который должен его согласовать, об этом даже может и не узнать. Вот у заказчика может не быть центра единого центра, который аккумулирует и контролирует прохождение документов по инстанциям.
330: Собирает комментарии, их преобразует в единый как бы список замечаний, отслеживает сроки, отслеживает как бы согласовантов, которые должны предоставить документы.
331: Какие мы видим подходы к решению? Ну, во первых, объём и формат документов должен быть адаптирован под потребности и возможности сотрудников предприятия. Количество документов должно быть минимально необходимо, а их формат должен быть максимально доступен для понимания ответственным. Вот.
332: То есть перед заключением договора, как я уже говорил, заказчик считает, что ему нужно полноценную документацию со схемами, с подробным описанием. Ну вот, а когда, ну это, конечно же, влияет на стоимость, сроки проекта, но когда эта документация ему будет подготовлена, полный пакет.
333: Оказывается, что она имеет очень большой объём, она сложна для понимания и прочтения лицам, которые должны ознакомиться с ней, её сложно поддерживать в актуальном состоянии, то есть это требует отвлечения ресурсов на поддержку.
334: Вот, и получается, что прочитать, согласовать этот объём документов, который они получили, сотрудники заказчика просто не успевают. Очень часто оказывается, что пользователям по итогу на самом деле были нужны небольшие инструкции по сложным момен.
335: У которого возникают затруднения и небольшая краткая памятка по перечню операций, ну, буквально перечень операций. К каким документам его необходимо оформить в системе? Вот. Плюс список изменений, которые были внесены в систему.
336: Не полное подробное там описание тз с интерфейсом и функционалом, нет, а просто напросто небольшой реестр операций, что было внесено, потому что если как бы исполнитель корректно комментирует свой код,
337: Проводит настройки, то в принципе, что было внесено, для каких целей можно
338: Понять, заглянув внутрь, внутрь системы. Вот
339: Вот так. Дальше какие мы видим решения? Это то, что промежуточные решения, согласование можно принимать в переписке по электронной почте. Вот перечень лиц, которые участвуют в рассмотрении согласования документов, должен быть ограничен только теми людьми, которые, которым эти документы
340: Относится непосредственно подключение лиц со смежных процессов, если они не участвовали в проработке, вот это просто затянет процесс согласование принятия документации, ну или решений. Вот надо чётко понимать тот
341: Чётко понимать тот объём, который мы согласовываем в настоящий момент. Если у нас есть смежные процессы, то их надо рассматривать отдельно, как отдельные задачи со своим списком, согласующих, вот, и принимающих решения. Работа по рассмот.
342: Согласование документов должны быть включены в план графика работ сотрудников заказчика. Ну, мы уже упоминали о том, что сотрудники заказчика должны иметь свой план, график работ, и эти работы по согласованию должны, не должны оказаться для них внезапными, они должны их как бы
343: Видеть и знать. Вот необходимо выделить ответственных лиц со стороны заказчика, то есть человека, который будет контролировать ход согласовательного процесса, оповещать ответственных, консолидировать замечания и приводить к единому реестру. Вот процесс.
344: Согласования. Перечень ответственных должен быть утверждён на предприятии. То есть все должны знать, за что они отвечают. Так, следующая причина риска это долгая реакция на текущие запросы исполнителя в ходе выполнения работ по проекту.
345: Это может, это проблемы, которые могут её вызывать. Это задержка подготовки выходных результатов проекта из за зависания уточнений. Ну то есть
346: Подготовили то есть или много вопросов, соответственно, они требуют долгих ответов или требуется внутреннее согласование у заказчика для того, чтобы принять какое-то единое решение. Это все приводит к тому,
347: Что вопрос подвис вот или же увеличение количества объёма формальной документации проекта для решения текущих вопросов.
348: Так какие мы видим решения? То есть, во первых, определить срок ответа и закрепить его. Ну то есть должен как бы в
349: Закреплён в договоре или в уставе проекта. Вот выделение 1 ответственного лица, которое вправе принимать решения по таким вопросам. То есть понятно, что это иногда сложно сделать на предприятии, то есть выделить 1 ответственного, лицо консолидированное.
350: Решение кажется, что это будет проще консолидированная ответственность, но надо понимать, что это очень сильно затормозит процесс продвижения проекта. То есть, если вопрос не настолько, скажем так, критичный,
351: То лучше отдать решение 1 ответственному лицу. Вот выделить ответственное лицо со стороны заказчика. Человек, который будет вести реестр запросов и добиваться ответа в сроки, установленные в договоре, решать попытаться решать вопросы на статус собра.
352: Вот, и закреплять решение в протоколе, то есть минимизировать формализм, минимизировать переписку, приходить к устному согласованию решения вопросов. Вот.
353: Таким образом, в текущем докладе мы рассмотрели те риски, которые возникают на большинстве проектов. Вот, и посмотрели, как бы их воздействие на проект, разобрали способ минимизации воздействия на проект. Вот перечень рисков.
354: На самом деле намного шире. Они могут быть индивидуальны для проекта, и способы их устранения также могут быть индивидуальны. Они могут зависеть и от проекта, и от предприятия, и от людей, которые работают на предприятии. Вот ключевые факторы, которые необходимо учитывать при проведении проекта, это заинтере,
355: Ованность руководства в проекте адекватная оценка наличия необходимых ресурсов человеческих, временных, денежных вот и планирование этих ресурсов, выделение необходимых ресурсов на проект и качественное плани.
356: Их работы.
357: Вот, то есть необходимо уделять внимание мотивации проектных команд, вот мотивации ключевых пользователей объяснять, зачем мы это делаем. Вот чётко следовать намеченному плану, всегда ориентироваться на те конечные цели, которые поставлены перед
358: Проектом не допускать распыления, потому что тогда цели проекта не будут достигнуты, вот или достигнуты не в те сроки, которые были обозначены ранее.
359: Вот при этом все-таки требуется осуществлять гибкость на проекте, проводить пересмотр целей. Если есть понимание, что требования бизнеса или ситуация на рынке изменилась. Вот основная все-таки ключевая точка в проекте, это желание и умение вести
360: Диалог, слаженное взаимодействие команд с 2 сторон во время проекта, то есть команда заказчика и команда исполнителя должны вместе работать над достижением целей. Вот этот подход помогает избежать рисков и завершить проект.
361: В соответствии с первоначальным планом. Итак, теперь вы знаете про те опасности, которые подстерегают на проекте, вот как обойти или нивелировать их. Вот, а значит, вероятность успешного завершения проекта становится ещё
362: Выше мы всегда ведём работу как бы по контролю за рисками проекта и принимаем все необходимые действия для их устранения. При совместной работе с нами вы можете быть уверены, что получите полную информацию о возможных проблемах. Вот и примеры успешных проектов это
363: Нас достаточно много. То есть это предприятие эра мурманский стрелочный завод, сск и много, много других. Вот подтверждает наш опыт, нашу квалификацию.
364: Владимир, спасибо большое. Он очень много информации. Я так думаю, что сегодня выдал. Надеюсь, что она была вам, коллеги, очень полезна. У нас ещё есть некоторое время.
365: Владимир, спасибо большое. Он очень много информации. Я так думаю, что сегодня выдал. Надеюсь, что она была вам, коллеги, очень полезна. У нас ещё есть некоторое время, когда мы готовы
366: Отвечать на ваши вопросы. Пожалуйста, задавайте их в чате. Если вопросы у вас появились, мысль, которую Владимир, да, попытался сегодня донести, что все-таки проект надо готовить, да, вот та информация, которую мы вам сегодня
367: Старались дать, она как раз касается в том числе подготовки проекта, потому что когда есть понимание, чего можно ожидать, да, какие подводные камни могут быть, то, соответственно, этим уже можно управлять. С этим можно работать. Вот как
368: 1 из инструментов успешной подготовки проекта. Мы считаем, что это либо предпроектное обследование, ну, в таком более широком ключе, либо это экспресс диагностика. Вот эту экспресс диагностику мы обычно прово
369: Дим в виде однодневного обследования. То есть это проходит интервью топ менеджеров и потом готовим отчёт для предприятия, где будут обозначены перечни приоритетных задач, рекомендации.
370: По выбору программного обеспечения, где будут даны рекомендации по последовательности внедрения, уже можно будет посмотреть, в какой бюджет ваше внедрение может вылиться и в какие сроки нужно закладывать на
371: Реализацию тем, кто сегодня подключился к вебинару, тем, кто активно участвовал, дослушал до конца. Есть специальное предложение для участников вот такой экспресс, такую экспресс диагностику.
372: 1 3 обратив обратившимся к нам предприятиям, мы готовы провести бесплатно, поэтому если вы как раз стоите на пороге реализации проекта ерпи или, может быть, какого-то другого проекта,
373: Base корпоративных решений 1 с. То такое мероприятие как экспресс диагностика может быть для вас крайне полезным QR-код здесь приведён на данной странице повто.
374: Что 1 производственным предприятиям, которые обратились, обратятся к нам за этой услугой после вебинара, мы готовы эту услугу предоставить бесплатно.
375: Пожалуйста, вопросы ваши пишите. Готова на них отвечать.
376: Я также сейчас в чат напишу наш электронный адрес, адрес департамента. Если у вас возникнут какие-то, может быть вопросы после уже
377: Завершение вебинара. Вы также можете нам их задать. Будем рады взаимодействию с вами.
378: Так, коллеги, да, электронный адрес выслала по собачка ИНН точка ру, поэтому ждём ваших обращений. Будем рады с вами продолжить.
379: Контактирование. Давайте буквально ещё пару минут. Я понимаю, что информации достаточно много, но, может быть какие-то вопросы у вас появятся.
380: Если вы уже сейчас в процессе реализации какого-то проекта на вашем предприятии, то может быть вы поделитесь вашим опытом, с какими из
381: Тех рисков, которые мы сегодня обсуждали, вы сталкивались, насколько успешно получилось их нивелировать, какие инструменты применяли, каким образом действовали. Я думаю, что вот эта информация для других слушателей
382: Будет очень полезно. Может быть у вас были какие-то риски, которые мы сегодня не обсуждали, но они
383: Имели достаточно большое влияние на проект, где-то были очень критичны. И если вы также этой информацией поделитесь, я думаю, что это будет тоже очень полезно и любопытно всем слушателям.
384: Ждём.