1С вопрос

Композиция делового письма обыкновенно трехчастна. Первая часть вводная (зачин), вторая часть основная, информативная, третья часть заключительная, резюмирует информацию и содержит пожелания дальнейшего сотрудничества.
Все речевые действия в деловом общении можно разделить на просьбы, сообщения, предложения и подтверждения. Структура письма может выглядеть следующим образом:
• Просим…
• Также просим…
• А также просим…
• Сообщаем…
• Одновременно сообщаем…
Выделение каждого речевого действия в самостоятельный аспект необходимо потому, что по каждой просьбе, по каждому предложению принимается самостоятельное решение.
Первая часть письма обычно содержит информацию о реальных, имевших место фактах, событиях (ссылка, мотивация, история вопроса); вторая часть называет желаемые, предполагаемые события.
Многоаспектное письмо представляет собой последовательно повторяющиеся содержательные аспекты, синтаксически оформленные в виде абзацев.
Для связи аспектов и содержательных фрагментов одноаспектных писем используются стандартные выражения:
• Во-первых… Прежде всего…
• Во-вторых… Затем…
• В-третьих… В заключение…
• Переходя к следующему вопросу…
• Что касается вопроса о…
• Учитывая все вышесказанное…
• Исходя из вышесказанного…
• В связи с необходимостью вернуться к вопросу о…
• Подводя итоги, необходимо подчеркнуть…
• В заключение выражаем надежду на…
• В заключение хотим напомнить Вам о…
Стандартные выражения деловой переписки
Первой частью любого письма (аспекта) является мотивация, объясняющая побудительные мотивы, причины составления текста.
Стандартные выражения, указывающие на причину
• По причине задержки оплаты…
• В связи с неполучением счета-фактуры…
• Ввиду несоответствия Ваших действий ранее принятым договоренностям…
• Ввиду задержки получения груза…
• Вследствие изменения цен на энергоносители…
• Учитывая, что производственные показатели снизились на…
• Учитывая социальную значимость объекта…
При ссылках
• Ссылаясь на Вашe письмо от…
• В соответствии с достигнутой ранее договоренностью…
• Ссылаясь на Ваш запрос от…
• Ссылаясь на устную договоренность…
• В ответ на Ваше письмо (запрос)…
• В соответствии с нашей договоренностью…
• На основании нашего телефонного разговора…
• На основании устной договоренности…
• Согласно постановлению правительства…
• Согласно Вашей просьбе…
• Согласно протоколу о взаимных поставках…
• Согласно спецификации…
• Ссылаясь на переговоры…
Указание на цель
• В целяx скорейшего решения вопроса…
• В целях выполнения распоряжения…
• Для согласования спорных вопросов…
• Для согласования вопросов участия…
• Для наиболее полного освещения деятельности Вашей oрганизации в СМИ.
• Для решения спорных вопросов…
• В целях безопасности прохождения груза…
• В ответ на Ваш запрос…
• Во избежание конфликтных ситуаций…
Все перечисленные выражения необходимо использовать с учетом контекста и речевой ситуации.
Стандартные фразы предваряют основную информацию, выраженную глагольной конструкцией, и соответствуют стандартным речевым ситуациям:
• этикетные ритуалы: благодарю, выражаю надежду, выражаем благодарность, желаем успехов, приносим извинения, выражаем соболезнование;
• сообщения: сообщаем, ставим Вас в известность, извещаем, уведомляем;
• подтверждения, заявления: подтверждаем, заверяем, заявляем, объявляем;
• требования, просьбы: приказываю, постановляю, настаиваем, прошу, обращаемся к Вам с просьбой;
• обещания: гарантируем, заверяем, обязуемся;
• напоминания: напоминаем;
• предложения: предлагаем.
Стандартизована в деловых письмах, равно как и в других типах документов, сочетаемость слов:
• контроль — возлагается,
• цена — устанавливается (снижается, поднимается),
• задолженность — погашается,
• сделка — заключается,
• рекламация (претензия) — предъявляется (удовлетворяется),
• платеж — производится,
• счет — выставляется (оплачивается),
• вопрос — поднимается (решается),
• скидки — предоставляются (предусматриваются),
• оплата — производится,
• возможность — предоставляется,
• договоренность — достигается,
• кредит — выделяется и т. п.
Сотрудничество чаще всего бывает плодотворным, взаимовыгодным,
деятельность — успешной,
вклад — значительным,
позиции — конструктивными (прочными),
доводы — вескими,
необходимость — настоятельной,
спектр (услуг) — широким,
скидки — значительными / незначительными,
предложение — конструктивным,
разногласия — существенными / несущественными,
рентабельность — высокой / низкой,
расчеты — предварительными или окончательными и т. п.

Лисин Н. Г.

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

Много говорят о том, что при внедрении ERP-класса недостаточно просто разработать Техническое задание (ТЗ), как это делается при внедрении систем учета хозопераций, а надо детально обследовать автоматизируемые бизнес-процессы предприятия, очень глубоко «встроиться” в жизнь пользователей и предприятия, выполнить моделирование бизнес-процессов в ERP-системе вместе с Заказчиком, двигаться итерациями в виде тестовых эксплуатаций с выявлением реальных, а не вымышленных требований…

Все это так. Но мы попробуем копнуть глубже.

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

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

Почему ERP сложнее внедрить чем учетную систему? Две проблемы

ERP – это не просто учетная система. Это система управления.

Система управления моделирует оперативную деятельность и взаимоотношения между сотрудниками, а также поддерживает оперативное принятие решений на основе получаемой информации.

Отсюда уже видно, насколько сложнее, по сравнению с учетной системой:

А) обеспечить функциональность ERP, соответствующую всем тонкостям работы предприятия – чтобы она облегчала работу сотрудников, повышала качество и скорость процессов, а не стала обузой, усложняющей работу;
Б) встроить ERP-программу в работу компании. Можно сказать, что внедрение ERP-это имплантация новой нервной системы в живой организм – предприятие.

Проблема № 1. Сложность определения оптимального функционала

Почему так сложно определить именно тот ERP-функционал, который будет оптимален для данного предприятия?

Все знают аксиому: «Практика – критерий истины». Что это значит в случае внедрения ERP-системы?

Это значит что никакие теоретические изыскания и моделирование, разговоры с пользователями, анализ их пожеланий, и постановки задач и так далее, не позволят написать ТЗ для настройки ERP-системы «под ключ». Нельзя подходить к ТЗ на ERP как к архитектурному проекту строительства, по которому можно качественно построить дом в соответствии со всеми требованиями.

Причина проста: архитектурный проект описывает целевой материальный объект, а ТЗ ERP описывает деятельность людей, во взаимосвязи различных событий и ситуаций.

Деятельность людей намного более многогранная и содержит множество нюансов.

– Материальный объект проще описать, представить заказчику во всех разрезах и свойствах, поскольку он статичен, а требования конечны. Дом не меняется с течением времени и имеет три измерения.
– Деятельность людей динамична, процесс разворачивается в четвертом измерении – времени…

Математики в таком случае говорят, что задача имеет «большую размерность”.

Какие следствия из этого утверждения?

Самое важное: понять как должна работать ERP-система на данном предприятии, можно только заставив пользователей начать в ней работать. Работать в прототипе, типовом тиражном решении, в котором есть более-менее приближенная к предприятию модель бизнес-процессов.

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

Надежды все расчертить, продумать, расписать в ТЗ, запрограммировать и получить в красивой обертке готовый работающий продукт – нереалистичны.

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

Видим, что проблема налицо, но мы постарались показать выше глубинные и объективные причины такого развития событий. Комикс не о бестолковости заказчика и разработчика, как можно подумать… Ничего таинственного! Просто ни заказчик, ни разработчик ни разу в жизни не видели качели. И вот к чему пришли в результате: качели в итоге получились, но не вполне удобные! Очевидно, что если бы сразу стали вешать веревки, прилаживать доски и пробовать конструкцию в деле, то результат получился бы куда лучше.

Со временем к вендорам и интеграторам начало приходить абсолютное понимание, как наиболее быстро и с наименьшими затратами создать и запустить ERP-систему. Этот подход, как было сказано выше, есть ни что иное, как «Доводка системы в процессе ее эксплуатации».

Вот веселый видеролик «Если бы программисты строили самолеты”:

Наглядно, не правда ли?

В мире 1С такие подходы называются «Технология быстрого внедрения», «Технология быстрого результата» и тому подобные.

Уже многие компании заявляют свое конкурентное преимущество:

«Пока наши конкуренты 3 месяца пишут ТЗ, мы за это время уже начинаем работать в типовом решении и выдаем первые результаты, дорабатываем на практике. А в ТЗ все предусмотреть нельзя».

Наши рекомендации

Итак, вопрос ставится так – что лучше:

А) обследовать процессы, моделировать, разрабатывать ТЗ?

Б) или сразу «бросаться в бой” пользуясь типовым функционалом?

По нашему мнению, однозначного рецепта на все случаи – нет. Более подробно об этом будет рассказано чуть ниже, здесь же дадим общие рекомендации.

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

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

Это наш классический подход к выполнению больших проектов.

О проектной технологии компании ИТРП (полный проектный) цикл можно прочитать

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

Проблема № 2. Имплантация системы в переменчивую среду

Теперь рассмотрим вопрос – почему так сложно встроить ERP в процессы компании, в отличие, например, от блока регламентированного учета?
Начнем с того, что система учета и система управления – это разные системы.

• Система учета – фиксирует прошедшие события.
• Система управления – фиксирует не только прошедшие, но и будущие события.

Прошлое – фиксировано, будущее переменчиво!

Регистрировать в системе будущие события намного сложнее. Потому что любое будущее событие, регистрируемое в системе, с некой вероятностью может быть пересмотрено и изменено. А у любого события есть следствия – зависимые события!

Соответственно, если изменяется «начальное” событие – то нужно внести изменения во все зависимые события.

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

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

Тронем одно звено – развалится вся цепочка!

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

А теперь ответим на вопрос – корректируется ли прошлое (данные учета)? Например, фактически выполненная хозоперация оприходования на склад товара. Ответ очевиден: да! Но только если нужно исправить ошибку ввода. Поскольку прошлое фиксировано, его нельзя изменить, а можно только правильно учесть…

Именно в этом состоит тайная причина сложности внедрение систем управления, по сравнению с системами учета!

Не зря общепринятым подходом в западных ERP системах является правило: зафиксированное событие нельзя изменить «задним числом». А только скорректировать, сторнировать другим событием (документом).

Проблема № 3. Пользователи – зло?

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

Первая часть статьи>>>

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

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

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

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

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

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

Новая система, таким образом, выключается из бизнес-процесса и существует в «параллельной реальности”.

Как с этим бороться? Один из методов – требовать предоставление всех отчетов, только полученных в новой системе.

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

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

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

Какой должна быть схема внедрения, чтобы оно прошло наиболее безболезненно и принесло максимальную пользу?

Ответим на эти вопросы.

Технология создания и внедрения ERP-системы.

Риски проекта внедрения ERP-системы

Читаем о рисках в проектах создания ERP-систем. В том числе невыдуманная история одного проекта – как организационные сложности заказчика привели к стагнации проекта. Обязательно прочитайте – не узнаете ли свое предприятие?

Достаточно часто нам требуется получить от пользователя какую-либо информацию — имя файла или каталога, цвет или шрифт. Для всего этого в 1С существуют диалоги. Код, который требуется для вызова диалога, довольно стандартный и мало чем отличается из раза в раз. Собственно именно о том, как вызвать различные диалоги в 1С 8.2 и 8.3 и пойдет речь.

Отмечу, что приведенные ниже примеры подходят для любых конфигураций 1С 8.2, а также для конфигураций 1С 8.3 у которых свойство конфигурации «Режим использования модальности» установлено как «Использовать» либо «Использовать с предупреждениями». Если же Вы имеете дело с конфигурацией 1С 8.3 не использующей модальность, то рекомендую прочесть статью о модальности в 1С.

Выбор каталога в 1С

1 2 3 4 5 6 7 &НаКлиенте Процедура ВыборКаталога(Команда) тДиалог = Новый ДиалогВыбораФайла(РежимДиалогаВыбораФайла.ВыборКаталога); Если тДиалог.Выбрать() Тогда Сообщить(тДиалог.Каталог); КонецЕсли; КонецПроцедуры

Выбор файла в 1С

Обращаю Ваше внимание, что несколько масок расширений в одном фильтре должны разделяться знаком — точка с запятой (в синтаксис-помощнике об этом по-моему не написано).

Сохранение файла в 1С

В этом диалоге свойство «фильтр» никак не влияет на расширение сохраняемого файла.

Выбор цвета в 1С

Никаких свойств кроме «цвет» (только чтение) у этого объекта больше нет.

Выбор шрифта в 1С

Единственное свойство этого объекта — «шрифт», доступно для записи.

Свойства объекта «ДиалогВыбораФайла» интуитивно понятный и, поэтому, отдельно описывать я их не буду (кроме тех, что уже описал).

Помимо метода «Выбрать», у всех перечисленных объектов существует метод «Показать», который позволяет передать обработку результатов выбора в какую-либо процедуру. Кроме этого, у объектов «ДиалогВыбораЦвета» и «ДиалогВыбораШрифта» метод «Показать» вызывает не модальную версию диалогового окна. Использование этого метода выглядит примерно так:

Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *