Нет рисунка
Изменение структуры распределенной информационной базы на периферийной запрещено и группы полей «Центральная информационная база» и «Текущая информационная база» носят чисто информационный характер.
Для осуществления выгрузки измененных данных на центральную ИБ нажмите кнопку «Выгрузить данные» диалога, в открывшемся окне введите спецификацию имени файла переноса данных и нажмите кнопку «ОК». В случае, если файл с таким именем уже существует, система выдаст предупреждение и запросит подтверждения.
При вводе имени файла можно указать пароль ZIP, защищающий файл переноса от несанкционированного использования.
Для осуществления загрузки измененных данных с центральной ИБ нажмите кнопку «Загрузить данные» диалога, в открывшемся окне введите спецификацию имени файла переноса данных и нажмите кнопку «ОК».
Если при выгрузке вводился пароль ZIP, то его необходимо указать при вводе файла.
В случае, если загрузку произвести невозможно (например, файл не является файлом переноса данных, сформированным Конфигуратором центральной ИБ), система выдаст предупреждение о причинах неудачной загрузки.
Автообмен в распределенной информационной базе может включать четыре действия:
• прием сообщений ЭП;
• загрузку изменений из центральной ИБ;
• выгрузку изменений в центральную ИБ;
• передачу сообщений ЭП.
Прием и передача сообщений ЭП предлагаются, если данная возможность определена в настройке автообмена.
При запуске диалога определяется, возможно ли произвести загрузку и выгрузку, и устанавливаются соответствующие признаки е диалоге. Если при настройке параметров автообмена каталог загрузки был установлен на сменный носитель, загрузку считается возможным произвести.
Указанные действия будут выполняться всегда в указанной последовательности. В диалоге следует отметить, какие из предложенных действий следует выполнять.
В окне имени файла выгрузки указывается ожидаемое имя. В процессе загрузки (а она происходит сначала) система может принять решение изменить имя файла выгрузки (например, если на центральной ИБ оно было изменено при настройке параметров автообмена).
Для старта операции автообмена нажмите кнопку «Выполнить».
Номера документов и коды элементов справочников
Синхронизация «ведущих» объектов распределенной информационной базы происходит в процессе обмена файлами переноса данных, в промежутках между обменами каждая ИБ работает автономно. Это может привести к тому, что созданному на одной из ИБ документу будет присвоен уникальный в пределах данной ИБ номер, который окажется не уникальным для всей распределенной информационной базы в целом. В таком случае, после обмена файлами переноса данных, в распределенной ИБ могут образоваться два (или больше) документа с одинаковыми номерами, даже если в свойствах номера документа установлены признаки «Контроль уникальности» и «Автоматическая нумерация». Аналогичная ситуация может возникнуть и для кода вновь созданного элемента справочника.
Рекомендуемый способ решения этой проблемы состоит в использовании префиксов номеров документов и кодов элементов справочников. В свойствах номера или кода при конфигурировании следует установить тип «Текстовый». В качестве префикса можно использовать значение локальной константы или код информационной базы. В случае использования локальной константы следует обеспечить уникальность ее значения для каждой ИБ в пределах распределенной ИБ. Если используется код информационной базы, уникальность обеспечивается автоматически, так как в одной информационной базе не может быть двух ИБ с одинаковым кодом - система следит за этим.
Для документов и справочников, имеющих свойство миграции «Место создания», обеспечивать уникальность номера или кода в пределах всей распределенной информационной базы не обязательно.
Пример:
// Установку префиксов производим в процедуре
// ПриКачалеРаботыСистемы глобального модуля
Процедура ПриНачалеРаботыСистемы() // Установка префиксов автонумерации
КодИБ = ТекущаяИБКодО ; // Использование кода ИБ ПрефиксАвтоНумерации("Справочник.Тов7'
// Использование значения локальной :•.
ПрефиксАвтоНумерации( "С-' --.--•--."•/ '•••-
Константа. Т.о'т ~ /I Использование кода :::
ПрефиксАвтоНумерации(•Г
КонецПроцедуры
Нормы общения
При общении с клиентом необходимо соблюдать определеные нормы общения.
Когда Вы или Ваш сотрудник встречается с клиентом, всегда необходимо представиться. Обязательно дайте сотрудникам клиента свою визитную карточку. Если Вы не уверены, как общаться с сотрудником клиента, то задайте ему вопрос об этом: «Извините, как Вам удобнее, чтобы я Вас называл - на «ты» или на «Вы»?». При этом всегда скажите, как удобнее называть Вас. Если вы не считаете возможным задавать такой вопрос, то правильно будет называть собеседника на «Вы».
Запрещается повышать голос на клиента.
Речь не должна содержать непонятных обеим сторонам жаргонных слов и выражений. Если Вам что-то непонятно в словах клиента, вежливо попросите его объяснить термин.
Никогда не надо опасаться лишний раз поблагодарить Вашего собеседника за предоставленную информацию или за проведенную беседу.
Обеспечение целостности данных
Обеспечение целостности данных
В Microsoft Access обеспечивается возможность автоматической проверки целостности данных в связанных полях. Целостность даных означает систему правил, используемых для поддержания связей между записями в связанных таблицах, а также для обеспечения защиты от случайного удаления или изменения связанных данных. Установить проверку целостности данных можно, если выполнены следующие условия:
связанное поле главной таблицы является ключевым полем или имеет уникальный индекс;
связанные поля имеют один тип данных. Здесь существует два исключения. Поле счетчика может быть связано с числовым полем, если в последнем поле в свойстве Размер поля (FieldSize) указано значение Длинное целое (Long Integer), или в обоих полях свойство Размер поля (FieldSize) имеет значение Код репликации (Replication ID);
обе таблицы принадлежат одной базе данных Microsoft Access.
Замечание
Таблицы одного приложения могут содержаться и в нескольких файлах базы данных (см. также гл. 3).
Невозможно ввести в связанное поле подчиненной таблицы значение, отсутствующее в связанном поле главной таблицы. Однако можно ввести пустое значение, показывающее, что для данной записи связь отсутствует.
Не допускается удаление записи из главной таблицы, если существуют связанные с ней записи в подчиненной таблице.
Невозможно изменить значение ключевого поля в главной таблице, если существуют записи, связанные с данной таблицей.
Чтобы эти правила контролировались для конкретной связи, при ее создании следует установить флажок Обеспечение целостности данных (Enforce Referential Integrity). Тогда любая попытка выполнить действие, нарушающее одно из перечисленных выше правил, приведет к выводу на экран предупреждения, а само действие выполнено не будет.
Чтобы преодолеть ограничения на удаление или изменение связанных записей, сохраняя при этом целостность данных, следует установить флажки каскадное обновление связанных полей (Cascade Update Related Fields) и каскадное удаление связанных записей (Cascade Delete Related Records). Если установлен флажок каскадное обновление связанных полей (Cascade Update Related Fields), то при изменении ключевого поля главной таблицы автоматически будут изменены и соответствующие значения поля связанных записей. Если установлен флажок каскадное удаление связанных записей (Cascade Delete Related Records), то при удалении записи в главной таблице удаляются и все связанные записи в подчиненной таблице.
Область применения
Методология и разработанные на ее основе методические материалы могут найти следующее практическое применение.
|
Внедрение и сопровождение |
Инструменты внедрения и сопровождения |
|
Руководство по внедрению и сопровождению системы «1С:Предприятие» |
|
|
Типовые формы документов |
|
|
Обучение и сертификация партнеров и специалистов |
Учебный курс, тема «Методология внедрения и сопровождения системы «1С:Предприятие» |
|
Программа сертификационных экзаменов, раздел «Методология внедрения и сопровождения системы «1С:Предприятие» |
|
|
Обучение клиентов |
Программа обучения, раздел «Методология внедрения и сопровождения системы « 1С:Предприятие» |
Обработка контакта
После получения первоначальной информации необходимо ее обработать. Результатом обработки должны явиться два основных момента:
1. Мы дальше отрабатываем этот контакт?
2. Если мы его отрабатываем, то КТО это делает.
Несмотря на кажущуюся парадоксальность первого вопроса, он достаточно важен. Фирма-франчайзи может не взяться за заказ по нескольким причинам:
отсутствие ресурсов - в данный момент времени сотрудники, специализирующиеся на этом направлении, заняты на другом заказе, а больше таких специалистов нет;
недостаточно опыта - Ваша фирма никогда не занималась автоматизацией определенного сегмента учета, а заказчик очень ответственный и нельзя ставить на нем эксперименты;
не договорились об оплате услуг;
после первой беседы с потенциальным клиентом выяснилось, что Ваши услуги не требуются: клиент искал другую систему (сроки, условия работы и т.д. и т.п.).
Обращение по электронной почте
Следует сказать несколько слов о Web-сайте компании. Хорошо спроектированный и оформленный Web-сайт может заменить демонстратора в продажах некоторых продуктов (особенно это касается ТОР).
Но даже если после просмотра Web-странички клиент не покупает продукт, то он может задать вопрос, положительный ответ на который явится для него (клиента) безусловным стимулом к покупке продукта.
Общение с клиентом
При работе с клиентом сотрудник обязан выполнять ряд правил. Соблюдение данных правил уменьшает количество конфликтных ситуации у клиента, приводит к более продуктивному сотрудничеству клиента и Вашего сотрудника.
Ниже. эти правила будут подробно рассмотрены.
Общие положения
В данном документе в конспективной форме приводятся описание методологии внедрения пакета прикладных программ "1С:
Предприятие". Под методологией понимается описание задач, их связей и общих подходов к их решению. Методология позволяет ответить на вопрос: «Что?». Ответ же на вопрос «Как?» дают конкретные методики и технологии, разрабатываемые на основе методологии.
Рассматриваемый подход к внедрению прикладных систем проверен многолетней практикой. Главной его особенностью является нацеленность на обеспечение качества. Качество при этом понимается конструктивно и включает следующие критерии:
удовлетворение бизнес-требований, т.е. требований к поддержке бизнеса клиента, (функциональность, рабочие характеристики, удобство эксплуатации и обслуживания), подтвержденное объективными данными тестирования;
получение результата при заданных ограничениях на сроки, бюджет и персонал.
Качество достигается за счет четкого определения бизнес-процессов и бизнес-требований предприятия в самом начале проекта и их последовательного отображения на процессы и базу данных внедряемой Прикладной системы.
В конечном итоге рассматриваемый Подход направлен на минимизацию затрат и времени при обеспечении гарантированного качества. Для этого используется тесная интеграция задач собственно внедрения с задачами управления проектом. Именно хорошая организация и управление проектом при правильной методологии дают гарантию успеха.
Рассматриваемая методология представляет собой адаптацию методов, предлагаемых ведущими консультационными и программными фирмами, применительно к конкретным условиям применения системы "1С: Предприятие". Несмотря на то, что изначально данный метод был разработан для средних и больших проектов, он применим и к сравнительно малым проектам.
В данном документе рассматривается в основном аспект методологии, описывающий структуру и связи задачи выполнения внедренческих работ. Также приводятся краткие сведения по процессам и задачам управления проекта. Организационный аспект, описывающий состав и функции группы внедрения, систему управления проектом, сетевые планы работ будут описаны в последующих документах.
В дальнейшем работы по созданию методического обеспечения проектов внедрения будут продолжены по следующим направлениям:
разработка методических руководств и документов для практического использования;
подготовка вариантов методологии для различных групп партнеров;
разработка, выбор и адаптация программных инструментов для решения задач внедрения и сопровождения.
В целом, методология внедрения должна послужить основой для разработки и внедрения новых стандартов качества деятельности компании «"1С"».
Общие принципы
Распределенная информационная база состоит из центральной информационной базы и произвольного числа периферийных информационных баз. Передача изменений производится посредством файла переноса данных.
Центральная информационная база - это единственная точка, где может модифицироваться конфигурация и откуда может осуществляться управление структурой распределенной информационной базы (составом входящих в нее периферийных информационных баз). Изменения данных (ввод и модификация документов, работа со справочниками и т.д.) могут производиться на любой ИБ распределенной информационной базы. Для синхронизации информационных баз между периферийными и центральной ИБ периодически производится перенос измененных данных. Периферийные ИБ, участвующие в процессе обмена данными, должны быть созданы на основе центральной ИБ (см. раздел «Создание образа периферийной ИБ») - в противном случае файл передачи данных компонентой обработан не будет.
Существует специальная возможность с . кия для периферийной ИБ признака «Только получатель», с этом случае будет выполняться перенос данных в периферийную информационную базу, но обратный перенос данных (из этой ИБ в центральную) выполняться не будет. Периферийные информационные базы с признаком «Только получатель» используются в специальных случаях. Например, чтобы иметь постоянно поддерживаемую в актуальном состоянии копию центральной ИБ, с возможностью внесения в нее любых изменений.
Перенос данных происходит «пообъектно», то есть единицей переноса информации является «ведущий» объект, документ, элемент справочника, константа. При использовании компоненты «Бухгалтерский учет» к таким объектам добавляются бухгалтерский счет, типовая операция, список корректных проводок (список корректных проводок, фактически, является одним объектом и при их изменении обновляется целиком). При использовании компоненты «Расчет» «ведущими» объектами также становятся календари (каждый календарь является самостоятельным «ведущим» объектом). Вместе с документом также переносятся все действия, которые он выполняет в процессе проведения: движения регистров, акты расчета, изменения в справочниках, бухгалтерские операции. При изменении в центральной информационной базе самой конфигурации системы в процессе переноса данных происходит также автоматическая реструктуризация данных во всех периферийных информационных базах.
При конфигурировании системы для различных видов объектов может быть определена область миграции: указаны те информационные базы, в которые должны попадать конкретные экземпляры объектов данного вида в зависимости от места их создания. Например, доверенности могут не участвовать в переносе информации, так как они обычно используются только "по месту выписки". Многие документы имеет смысл переносить только на центральную информационную базу для получения консолидированной отчетности. Каждая ИБ автоматически ведет внутренний список изменений "ведущих" объектов, постоянно пополняя его. В выгружаемый файл также помещается информация о загруженных изменениях объектов. При загрузке ИБ определяет, какие изменения приняты ее корреспондентом, и удаляет их пз списка изменений. Кроме обычного автоматического способа регистрации изменений ведущих объектов существует возможность управлять включением объекта в список измененных. Управление выполняется средствами встроенного языка и используется в специальных случаях. Например, с помощью такого управления можно исключить передачу изменений объекта, выполненных специальной обработкой, если они заведомо имеют смысл только в данной информационной базе. Реализация механизма передачи данных между ИБ обеспечивает корректную синхронизацию информационных баз в случаях, когда нарушается порядок загрузки файлов переноса данных, и даже в случае потери части выгрузок. Однако этот механизм подразумевает обмен файлами переноса данных в обоих направлениях, так как до тех пор, пока от ИБ, для которой производилась выгрузка, не вернется подтверждение приема изменений, ИБ, производившая выгрузку, будет включать, возможно, уже принятые изменения в каждый последующий файл переноса данных, что будет увеличивать размер файла.
Обучение
Обучение является очень важным этапом во всем процессе внедрения. Фактически обучение начинается после того, как клиенту установлена система и он начинает работать на ней. Правильно и качественно проведенное обучение является залогом успешной и надежной работы системы.
Необходимо помнить о том, что без наличия лицензии на образовательную деятельность нельзя упоминать о самом факте обучения. В этом случае разумно говорить об оказании консультационных услуг, связанных с каким-либо программным продуктом.
Основными этапами обучения являются:
план занятий - должен быть составлен до начала обучения, с ним должны быть ознакомлены обучаемые сотрудники заказчика;
график занятий - должен быть составлен до начала обучения, с ним должны быть ознакомлены обучаемые сотрудники заказчика. Нарушение графика не приветствуется;
методические материалы - в них должны быть описаны ключевые моменты системы, по которой проводится обучение. Очень хорошим вариантом будет включение в методические материалы FAQ по продукту. Целесообразно предоставление Руководства, специально написанного для данного клиента (разумеется, если это оговорено заранее).
аттестация после проведения обучения является дополнительным механизмом контроля качества того, как сотрудники заказчика поняли принципы работы системы. Только после прохождения аттестации можно допускать сотрудника заказчика к работе с системой.
Описание выполняемых задач процесса внедрения
1. Заказ на внедрение.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ (здесь и далее: или диспетчер) принимает заказ от клиента, если тот обращается за оказанием услуг внедренческой фирмы.
2. Оформление и подготовка заказа.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ должен заполнить бланк заказа утвержденной формы в журнале заказов. Все поля бланка заполняются в обязательном порядке на основе диалога с клиентом (рекомендации по перечню необходимых сведений и форме бланка заказа см. [I, раздел 3.2.1, 7.11], [2, раздел «Типовая организация обслуживания»]).
Затем подготавливается сопроводительный ПАКЕТ ДОКУМЕНТОВ и ПРОДУКТОВ для заказа: документы, требуемые для оформления взаимоотношений с заказчиком и закрытия выполненных работ, сопроводительная методическая документация и продукты, набор рекламно-информационной продукции. Рекомендации по формам документов и методике их оформления см. [1, разделы 3.2.5, 7.2-7.10].
Проверяется наличие на складе ПРОГРАММНОГО ПРОДУКТА, в том случае, если внедрение включает его доставку и установку.
Ответственным за подготовку пакета документов и продуктов является руководитель отдела внедрения.
3. Определение исполнителей для начального этапа внедрения.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ определяет исполнителя для начального этапа работ у клиента.
Основные критерии выбора: специфика заказа, предметная специализация (компонента 1С:Предприятия, спектр выполняемых услуг и пр.) и опыт «кандидата», отраслевая специализация (наличие «готовых решений» и наработок на рынке деятельности заказчика), текущая загрузка.
Далее руководитель отдела внедрения ставит задачу исполнителю на выполнение работ, исходя из данных бланка соответствующего заказа и диалога с клиентом.
4. Предварительный анализ задачи.
ЭКСПЕРТ (в т.ч. технический специалист) должен подготовиться к предварительной беседе с клиентом на основе бланка заказа и обсуждения задачи с руководителем отдела внедрения.
Далее эксперт связывается с клиентом для выяснения деталей предстоящей автоматизации, договаривается о своем визите.
Эксперт должен взять с собой на заказ ПРОГРАММНЫЙ ПРОДУКТ (в случае надобности; и проверив работоспособность ключа защиты и носителей информации) и ПАКЕТ ДОКУМЕНТОВ, уточнив при необходимости правильность их заполнения.
5. Начальное обследование объекта.
ЭКСПЕРТ выезжает для выполнения заказа на основании договоренности с клиентом.
На месте экспертом уточняется предполагаемый спектр реальных задач внедрения (в т.ч. определяется круг первоочередных задач автоматизации). При необходимости вносятся соответствующие корректировки.
Здесь важно добиться одинакового понимания проблем, для чего уже на этом этапе начинается процесс ПОДГОТОВКИ специалистов заказчика к различным аспектам внедрения, его технологическим и организационным особенностям.
Эксперт при выполнении задачи 5 должен выяснить и зафиксировать всю необходимую информацию, в том числе для более точной оценки категории (см. задачу 7) и объема внедрения, а также возможностей клиента. Рекомендации по списку необходимых сведений см. [1, раздел 3.2.1].
Рекомендации по методике общения с клиентами и ведению переговоров см. соответственно [1, разделы 3.2.2 и 3.2.3].
6. Определить союзника внедрения.
Одной из важнейших задач ЭКСПЕРТА при выполнении задачи 5 является определение отв. лица или круга лиц со стороны заказчика, которые в первую очередь заинтересованы в успешной автоматизации. Тесное сотрудничество с ними при выполнении внедрения поможет сделать работу эксперта более продуктивной. Возможные варианты см. в задаче 13.
Кроме того, важно обеспечить: а) поддержку внедрения со стороны руководства заказчика, б) понимание важности внедрения как такового со стороны всех причастных к этому лиц заказчика.
ПРИМЕЧАНИЕ: Желательно определить союзника внедрения и заручиться его поддержкой (важно создать КОМАНДУ внедрения, в которую, кроме эксперта, входили бы представители заказчика) как можно раньше, однако не всегда на данном этапе это бывает возможным, особенно в комплексных внедрениях.
7. Анализ категории внедрения.
ЭКСПЕРТ на основании предварительной оценки делает вывод о предполагаемой категории внедрения.
ПРИМЕЧАНИЯ: 1) Понятие КАТЕГОРИИ внедрения вводится для их ранжирования, что предполагает а) более объективную оценку своих возможностей и ресурсов при обслуживании заказа, 6) более четкое следование дальнейшим этапам цепочки технологии внедрения.
2) Масштаб и сложность внедряемой системы, условия ее сопровождения должны быть адекватны уровню фирмы-франчайзи.
3) Границы представленных категорий внедрений весьма условны; часто в процессе реальной работы происходит плавный переход внедрений из младших категорий в старшие.
Категории внедрения
7А. Категория А:
Внедрение НАЧАЛЬНОГО УРОВНЯ.
ВОЗМОЖНЫЕ ЗАДАЧИ: установка и начальное обучение (гарантированный сервис) после чего пользователь предполагает начать самостоятельную работу с использованием типовой конфигурации, небольшие консультации по использованию типовой конфигурации системы.
ОБЪЕМ ЗАКАЗА: ограничивается обычно 10-ю часами работы специалистов франчайзи (1-2 визита).
ОСНОВНЫЕ ЗАКАЗЧИКИ: небольшие фирмы.
ТИП ПОСТАВКИ: работа обычно в локальной версии 1С: Предприятия на основе типовой конфигурации (используется чаще всего компонента 1С:Бухгалтерия).
7Б. Категория Б:
НЕБОЛЬШОЕ внедрение.
ВОЗМОЖНЫЕ ЗАДАЧИ: гарантированный сервис, конвертация базы при переходе с предыдущих версий программы (или других программ), незначительное изменение плана счетов, незначительная переделка форм и отчетов, обучение работе с программой, консультации и пр.
ОБЪЕМ ЗАКАЗА: от 10 до 50 часов работы специалистов франчайзи (2-10 визитов в течение месяца или разовые визиты в процессе эксплуатации системы).
ОСНОВНЫЕ ЗАКАЗЧИКИ: небольшие и средние фирмы.
ТИП ПОСТАВКИ: работа в локальной, 3-х пользовательской или сетевой версиях 1С:Предприятия (используются чаще всего 1-2
компоненты системы: ВЕДУЩЕЙ может быть любая из компонент в зависимости от профиля фирмы заказчика; 1С:Бухгалтерия при этом используется практически всегда).
7В. Категория В:
КОМПЛЕКСНОЕ внедрение.
ВОЗМОЖНЫЕ ЗАДАЧИ: комплексная поэтапная работа: всестороннее обследование объекта, составление ТЗ, разработка конфигурации, обучение персонала, ввод конфигурации в эксплуатацию, подготовка пользовательской документации, комплексное сопровождение и пр.
ОБЪЕМ ЗАКАЗА: не менее 30 часов работы специалистов франчайзи.
ОСНОВНЫЕ ЗАКАЗЧИКИ: средние и достаточно крупные фирмы;
ТИП ПОСТАВКИ: работа в сетевой версии 1С:Предприятия (используется чаще всего комплексная конфигурация, ВЕДУЩЕЙ может быть любая из компонент в зависимости от профиля фирмы заказчика).
ПРИМЕЧАНИЯ: 1) Необходимо четкое понимание руководством фирмы-франчайзи следующего непременного условия: Только наличие соответствующей инфраструктуры позволяет рассчитывать на успешную работу над внедрениями категории В.
2) Внедренческая структура должна быть готова: а) подключиться к автоматизации системы у клиента на любом из ее этапов, б) к возможной замене конкретных исполнителей проекта.
Для внедрений КАТЕГОРИЙ А и Б: задачи 8-11.
8. Решение первоочередных задач автоматизации.
ЭКСПЕРТ должен в первую очередь решить наиболее острые и неотложные задачи автоматизации заказчика (и желательно при первом же визите), которые были определены при начальном обследовании объекта (см. задачу 5).
См. также рекомендации по выполнению работ задачи 15.
9. Задача «закрепления» клиента.
ЭКСПЕРТ и фирма-франчайзи в целом в своей работе должны РУКОВОДСТВОВАТЬСЯ УСТАНОВКОЙ: «Каждый клиент должен стать постоянным для эксперта и фирмы и оставаться им на всем цикле эксплуатации 1С:Предприятия».
Оперативное и квалифицированное решение первоочередных задач внедрения - это не только качественное выполнение текущего заказа, но и работа «на перспективу».
ЭКСПЕРТ во время работы над заказом должен:
продемонстрировать высокий профессиональный уровень (рекомендации по обеспечению качества выполнения работ см. [1, раздел 3]) и высокий уровень общения для создания благоприятной среды, в которой будет проходить внедрение (см. рекомендации [1, разделы 3.2.2, 3.2.3]);
предложить свои идеи по усовершенствованию системы, а возможно и помощь в разработке стратегии автоматизации клиента (что является новым качеством внедрения фирмы-франчайзи);
подробно проинформировать клиента о своей фирме, ее услугах и возможностях, инициалы ответственных по направлениям, системе сопровождения пользователей и т.п. Оперативность и точность получения последующей от клиента информации обеспечит более оперативную реакцию на обращения.
ПРИМЕЧАНИЕ: Задача «Закрепления клиента» (см. УСТАНОВКУ в задаче 9) стоит на всех этапах внедрения и для всех его категорий.
10. Закрытие выполненных работ.
Для закрытия выполненных работ ЭКСПЕРТ должен:
оформить и подписать у отв. представителя заказчика весь пакет соответствующих документов и протоколов (акты о выполнении работ, другие первичные документы, специализированные документы и протоколы);
получить расчет от заказчика (или проконтролировать поступление средств на расчетный счет в случае безналичной оплаты).
Далее ЭКСПЕРТ вносит перечень проделанных у клиента работ в ОТЧЕТ ЭКСПЕРТА (рекомендации по формам такого отчета см. [1, раздел 7.12], другие рекомендации по отчетности экспертов см. [2, раздел «Типовая организация обслуживания клиентов»]). Отчет раз в неделю лично сдается РУКОВОДИТЕЛЮ ОТДЕЛА ВНЕДРЕНИЯ и комментируется экспертом. Отчет (включая его устную форму) в данном случае служит для регулярного контроля процесса внедрения. Руководитель отдела внедрения визирует сданный экспертом отчет.
Только после этого заказ можно считать ВЫПОЛНЕННЫМ и ЗАКРЫТЫМ.
Здесь полезны рекомендации по типу документов и их оформлению [1, раздел 3.2.5].
11. Заказчик идет на дальнейшее сотрудничество?
Производя закрытие выполненных работ, ЭКСПЕРТ должен еще раз поинтересоваться у отв. представителей заказчика о планах на дальнейшее сотрудничество. Если заказчик взял время на обсуждение, необходимо договориться о дате возможных контактов. Эксперт должен поставить в известность РУКОВОДИТЕЛЯ ОТДЕЛА ВНЕДРЕНИЯ о дальнейших планах заказчика.
Для внедрений КАТЕГОРИИ Б: задачи 12-16.
12. Перспективное планирование работ.
ЭКСПЕРТ в переговорах с отв. представителями заказчика должен согласовать предполагаемый порядок дальнейших действий и составить на основе этого проект ( ПЛАНА ) ГРАФИКА РАБОТ (по возможности максимально подробно с указанием предполагаемых сроков).
Далее эксперт должен оговорить с заказчиком даты и время ближайших контактов.
13. Оценка «перспективности» заказчика.
ЭКСПЕРТ в процессе сотрудничества с заказчиком вырабатывает оценку его «индивидуальных» особенностей и перспективности внедрения. ОЦЕНКА «перспективности» заказчика оформляется в виде рабочего документа для внутреннего пользования и передается руководителю отдела внедрения. Далее сведения «Оценки...» должны размещаться в базе сводных данных о клиенте (данные исключительно для внутреннего пользования с ограничением прав доступа к ним).
Примеры полей «Оценки...» (возможны дополнения):
1. Название организации, адрес, телефон;
2. Контактные лица;
3. Масштаб организации: а) небольшая, б) средняя, в) крупная. Комментарии к каждому варианту;
4. Наличие удаленных отделений и филиалов, их количеств, местонахождение. Комментарии к каждому варианту;
5. Численность рабочих мест (в т.ч. одновременно работающих в системе). Комментарии;
6. Объем документооборота;
7. Профиль деятельности: а) розничная торговля, в) оптовая торговля, в) производство, г) бюджетная структура, д) другое. Комментарии к каждому варианту;
8. Отраслевое направление деятельности. Комментарии;
9. Целесообразный масштаб автоматизации по оценке эксперта: а) небольшой, б) довольно большой, в) очень большой. Комментарии к каждому варианту;
10. Клиент оценивает перспективный масштаб автоматизации: а) в основном правильно, б) недостаточно правильно, в) неправильно. Комментарии к каждому варианту;
11. Платежеспособность клиента: а) готов платить всегда, б) готов платить при строгом контроле работ и их стоимости, в) платит «со скрипом», г) практически не готов платить. Комментарии к каждому варианту;
12. Кто из отв. представителей клиента в первую очередь заинтересован во внедрении: а) РУКОВОДИТЕЛЬ (зам. руководителя), б) ПРОГРАММИСТ (системный администратор и т.п.), в) БУХГАЛТЕР, г) МЕНЕДЖЕР (руководитель направления фирмы и т.п.), д) Другие сотрудники. Комментарии к каждому варианту;
13. Кто из отв. представителей клиента не поддерживает внедрение: а) РУКОВОДИТЕЛЬ (зам. руководителя), б) ПРОГРАММИСТ (системный администратор и т.п.), в) БУХГАЛТЕР, г) МЕНЕДЖЕР (руководитель направления фирмы и т.п.), д) Другие сотрудники. Комментарии к каждому варианту;
14. Адекватность восприятия происходящего и уровень общения отв. лиц клиента в процессе внедрения: а) работается комфортно, б) работается нормально, в) работается некомфортно г) работать невозможно (скандальный клиент). Комментарии к каждому варианту;
15. Инициалы отв. эксперта от франчайзи.
ПРИМЕЧАНИЕ: Желательно составить подобную оценку как можно раньше. но в дальнейшем оценка может корректироваться.
14. Выработка системы отношений с заказчиком.
ЭКСПЕРТ в согласовании с руководителем отдела внедрения на основе данных, полученных при выполнении задач 12 и 13, вырабатывает модель поведения по отношению к клиенту.
Далее оговаривается СИСТЕМА ОТНОШЕНИЙ (договорные и финансовые) заказчика и исполнителя, определяются условия взаимодействия, порядок разрешения споров и противоречий. Здесь полезными будут рекомендации и примеры форм документов [1, разделы 3.2.3, 3.2.5, 7.2-7.10].
Затем согласуется ГРАФИК РАБОТ, который оформляется в виде рабочего документа с визированием со стороны заказчика и исполнителя (в редких случаях допускается устная форма договоренностей).
Выполняя весь цикл согласований задачи 14, эксперт при необходимости может обращаться за советами к руководителю отдела внедрения.
ПРИМЕЧАНИЕ: График работ может корректироваться по условиям выполнения текущих работ внедрения.
15. Выполнение текущих работ.
Задача ЭКСПЕРТА при выполнении работ - добиться максимальной эффективности работы системы заказчика, исходя из существующих условий. Рекомендации по обеспечению качества выполнения работ см. [1, раздел 3]).
Эксперт для данной категории внедрения является: а) непосредственным исполнителем внедрения, б) координатором внедрения от исполнителя с довольно широким кругом полномочий при решении вопросов и разрешении проблем.
Необходимо понимание экспертом технологической цепочки своей фирмы, ее возможностей, уровня и наличия специалистов для принятия четких и оперативных действий по всему комплексу обслуживания со стороны внедренческой фирмы.
Эксперт должен заслужить хорошую репутацию у заказчика профессиональной работой, заинтересованностью при решении проблем заказчика, пунктуальностью, высоким уровнем общения, опрятным внешним видом и т.п. НЕОБХОДИМО постоянно поддерживать репутацию и авторитет своей фирмы при выполнении работ. Этому, в частности, способствуют: рациональное использование времени работы с клиентом (что-то необходимо оставлять на проработку сотрудникам пользователя, ставить перед персоналом клиента конкретные цели и задачи) и основных усилий по внедрению (например, обучение штатного программиста заказчика, способного в дальнейшем обслуживать систему), возможные небольшие переработки.
Важным здесь является также необходимость обеспечения информированности о всех аспектах внедрения причастных к этому лиц со стороны заказчика.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ должен осуществлять постоянный контроль качества выполнения работ. Рекомендации по контролю качества обслуживания см. [1, раздел З.З.З].
16. Закрытие выполненных работ.
По аналогии с задачей 10.
Производя закрытие выполненных работ, ЭКСПЕРТ должен еще раз поинтересоваться у отв. представителей заказчика о планах на дальнейшее сотрудничество и оговорить даты и время ближайших встреч.
Для всех категорий внедрений: задача 17.
17. Система сопровождения пользователей.
На фирме-франчайзи должна быть поставлена отлаженная СИСТЕМА СОПРОВОЖДЕНИЯ ПОЛЬЗОВАТЕЛЕЙ. Это один из ключевых элементов долгосрочного сотрудничества с клиентом.
Элементы системы сопровождения пользователей: линия консультаций, обновления из офиса и С выездом к клиенту, ИТС, специализированные семинары, абонементное обслуживание, сетевой и технический консалтинг и поддержка и пр. (рекомендации по сопровождению пользователей см. [2, раздел «Типовой набор услуг»]).
Для внедрений КАТЕГОРИИ В: задачи 18-42
Предварительный этап внедрения
18. Выработка системы отношений с заказчиком.
В переговорах с отв. представителями клиента вырабатывается СИСТЕМА ОТНОШЕНИЙ (договорные и финансовые) заказчика и исполнителя, определяются условия взаимодействия, порядок разрешения споров и противоречий. Здесь полезными будут рекомендации и примеры форм документов [1, разделы 3.2.3, 3.2.5, 7.2-7.10].
Со стороны франчайзи основные переговоры обычно ведет РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ (здесь и далее: или руководитель группы по работе над комплексными заказами для крупных внедренческих структур) с возможным привлечением руководителя фирмы и ведущего эксперта.
19. Определение постановщика проекта.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ определяет кандидатуру ПОСТАНОВЩИКА проекта. При этом учитываются мнения и пожелания: отв. представителей заказчика, руководителя внедренческой фирмы, возможных «кандидатов».
Кандидатура ПОСТАНОВЩИКА проекта выбирается из числа экспертов наиболее высокого класса фирмы-франчайзи. Это должен быть опытный специалист-универсал (аттестованный чаще всего по нескольким компонентам 1С:Предприятия). Выбор должен также учитывать: отраслевую специализацию эксперта (наличие «готовых решений» и наработок на рынке деятельности заказчика), текущую загрузку.
ЭТАП 1 внедрения: Комплексное обследование, выбор системы, составление ТЗ и графика работ
20. Договор на обследование объекта и составление ТЗ.
РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ и отв. представителями заказчика вырабатывается и подписывается ДОГОВОР НА ОБСЛЕДОВАНИЕ ОБЪЕКТА И СОСТАВЛЕНИЕ ТЗ (по результатам договоренностей задачи 18). В нем оговариваются только условия и сроки выполнения этапа I внедрения: комплексное обследование, составление ТЗ и плана графика работ. Только после выполнения этапа I внедрения можно детально обсуждать условия и сроки выполнения последующих этапов внедрения (хотя, во многих случаях с заказчиком приходиться предварительно обсуждать ориентировочный бюджет проекта автоматизации).
Продолжительность выполнения этапа I внедрения составляет обычно не менее двух недель.
Здесь могут быть полезны рекомендации по форме договора [1, раздел 7.5].
21. Комплексное обследование объекта.
Этап I внедрения выполняется в основном ПОСТАНОВЩИКОМ проекта. Однако, для обсуждения специфических вопросов внедрения (в т. ч. вопросов технического характера), окончательной оценки трудоемкости написания конфигурации постановщик должен провести соответствующие консультации с другими специалистами и кодировщиками.
Задача ПОСТАНОВЩИКА при выполнении этапа I внедрения -во взаимодействии с отв. представителями заказчика выработать максимально эффективную модель автоматизированной системы учета предприятия, исходя из существующих условий (бюджет проекта, сроки).
Эксперт-постановщик проекта для внедрений категории В является а) непосредственным исполнителем, как минимум, этапа I внедрения, б) координатором внедрения от исполнителя на всех его этапах с широким кругом полномочий при решении вопросов и разрешении проблем.
Эксперт при выполнении задачи 21 должен выяснять и зафиксировать всю необходимую информацию. Эти сведения станут основой для правильного выбора системы, успешного составления ТЗ и плана графика работ (рекомендации по списку необходимых сведений см. [1, раздел 3.2]). Они помогут также при составлении ОЦЕНКИ "ПЕРСПЕКТИВНОСТИ" ЗАКАЗЧИКА (см. задачу 23).
Здесь и далее см. также рекомендации задачи 15 «Выполнение текущих работ».
22. Задача «закрепления» клиента.
По аналогии с задачей 9.
23. Оценка «перспективности» заказчика.
По аналогии с задачей 13.
24. Выбор системы.
На основе данных, полученных при выполнении комплексного обследования (задача 21) ПОСТАНОВЩИК (в согласовании с руководителем отдела внедрения и техническими специалистами фирмы-франчайзи) вырабатывает предложение для заказчика о возможных вариантах поставки системы. Предложение описывает характеристики предлагаемых вариантов и указывает их стоимость. Рекомендации по процедуре выбора системы см. [2, раздел «Типовой набор услуг»].
Заказчик принимает решение о том, на основе какого варианта поставки будет производиться внедрение. Закупка же самого продукта не обязательно возможна именно здесь. Она может состояться и несколько позже или в принципе не состояться, если заказчика не будут удовлетворять результаты выполнения этапа I внедрения.
25. Составление ТЗ и графика работ.
ТЗ является концептуальным документом, подтверждающим одинаковый подход сторон к пониманию и решению конкретных задач по автоматизации учетного процесса.
ЭКСПЕРТ- постановщик проекта является отв. исполнителем задачи 25. При этом он должен добиться от руководства заказчика, чтобы с ним тесно сотрудничал опытный специалист (или группа специалистов) заказчика, хорошо понимающий особенности технологии работы и учета своего предприятия. Эксперт обязан предупредить о высокой ответственности заказчика за согласование разрабатываемого ТЗ.
Тщательно проработанное и правильно составленное ТЗ значительно снижает стоимость внедрения и сокращает сроки его выполнения, что в свою очередь является хорошей базой для дальнейшего сотрудничества с заказчиком.
При составлении ТЗ следует учитывать, что оно может быть успешным только в том случае, если основные трудозатраты по его составлению пришлись на долю представителей заказчика. Работа эксперта на данном этапе в основном состоит в правильном понимании потребностей заказчика, их соотнесении с реальными возможностями программного продукта, а также в оформлении пожеланий заказчика в виде документа.
С другой стороны, не следует забывать, что комплексное внедрение зачастую предполагает внесение серьёзных изменений в бизнес-процесс заказчика. Естественно, не каждый заказчик готов самостоятельно оценить необходимость и масштаб подобных изменений. Поэтому роль постановщика задачи в подобных случаях должна состоять не только и не столько в терпеливом выслушивании пожеланий заказчика, сколько в выявлении тех особенностей учета, которые могут помешать внедрению новых информационных технологий. При выявлении таковых необходимо, прежде всего, указать заказчику на возможную нестыковку и предложить способы ее устранения.
При выполнении задачи 25 ЭКСПЕРТ должен регулярно консультироваться с РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ (в том числе при определении предполагаемых сроков выполнения и стоимости работ по следующему этапу внедрения).
26. Закрытие этапа 1 внедрения.
ЭКСПЕРТ- постановщик проекта должен подписать ТЗ и график работ у отв. представителя заказчика (в данном случае чаще всего им является один из руководителей фирмы). Далее по аналогии с задачами 10 и 16.
27. Заказчик идет на дальнейшее сотрудничество?
По аналогии с задачей 11.
ЭТАП II внедрения: Разработка конфигурации и ввод ее в эксплуатацию
28. Договор на внедрение.
РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ и отв. представителями заказчика вырабатывается и подписывается ДОГОВОР НА ВНЕДРЕНИЕ (по результатам подписанных ТЗ и плана графика работ). В нем оговариваются условия и сроки выполнения этапа II внедрения, который включает: разработку конфигурации, тестирование конфигурации, обучение администраторов и персонала, подготовку пользовательской документации, сдачу-приемку конфигурации, опытную эксплуатацию.
Продолжительность выполнения этапа II внедрения составляет обычно не менее одного месяца.
Рекомендации по форме составляемого договора см. [1, раздел 7.6].
29. Есть ли потребность в дополнительных исполнителях?
Комплексное внедрение, как правило, предполагает участие группы экспертов. Ведущая роль, как уже говорилось, принадлежит ПОСТАНОВЩИКУ проекта. Кроме него, в разработке может принимать участие один или несколько специалистов-кодировщиков, главная задача которых состоит в написании тех документов и отчетов, которые требуются постановщику. На завершающем этапе потребуется специалист по обучению персонала заказчика.
К этой работе полезно привлечь эксперта (не кодировщика) имеющего больше опыта в общении с людьми, нежели с программированием.
30. Определение и подключение дополнительных исполнителей.
Проекты по внедрению, в которых принимают участие несколько исполнителей, гораздо более сложны в управлении, однако именно в таких проектах эффективность работы фирмы наиболее высока. В тех случаях, когда мы имеем большой объем работ, причем зачастую в смежных областях (например, стыковка с торговым оборудованием и сложный бухгалтерский учет), либо проект имеет жесткое ограничение по срокам, оправдано привлечение к работе нескольких специалистов. При этом возможно назначение РУКОВОДИТЕЛЯ ПРОЕКТА (особенно это характерно для крупных и многогранных задач), которому передаются все необходимые полномочия и на которого возлагается вся полнота ответственности за его выполнение. В разных случаях функции руководителя проекта могут осуществлять ПОСТАНОВЩИК или руководитель группы по работе над комплексными заказами.
Вопросы по определению и подключению дополнительных исполнителей и возможному назначению руководителя проекта решает руководитель отдела внедрения в консультациях с постановщиком (при возможном обсуждении с руководителем фирмы-франчайзи).
31. Разработка конфигурации.
На основе ТЗ разрабатывается конфигурация, учитывающая конкретные потребности заказчика.
При разработке конфигурации силами группы специалистов большое значение имеет координирование общей работы. В этой связи, целесообразно, чтобы структура данных описывалась постановщиком. Создается макетная конфигурация, в которой не прописаны модули, а лишь заданы основные типы данных и написаны черновые варианты описаний к документам, чтобы в дальнейшем эта информация была руководством к действию отдельным исполнителям.
Никакой тип данных не должен меняться без согласования с постановщиком, иначе непредвиденные изменения в данных, осуществленные разными людьми, могут вступить в противоречие и затянуть выполнение задачи в целом. Изменения процедур и функций в Глобальном модуле тоже не допустимы без согласования с тем исполнителем, который эту процедуру или функцию написал. Для этого желательно, чтобы в виде ремарок, в Глобальном модуле было видно авторство процедур и функций.
Каждый исполнитель должен понимать идеологию задачи, а не только «свой кусок». Для этого постановщик так формулирует информацию о задаче, чтобы каждый исполнитель понял ее взаимосвязи (но не в ущерб конфиденциальности).
Безусловно, на этапе составления ТЗ не исключены ошибки. Поэтому, в процессе создания конфигурации эксперт обязан внимательно проработать каждый пункт ТЗ.
В случае необходимости или явной предпочтительности применения механизмов отличных от тех, которые указаны в ТЗ, эксперт имеет право отступать от таких механизмов и требований ТЗ в рамках предварительной договоренности с заказчиком.
В случае необходимости внесения принципиальных изменений в ТЗ, эксперт инициирует дополнительные переговоры с представителями заказчика для разрешения всех появившихся вопросов. Уровень представителей со стороны Заказчики и Исполнителя определяется исходя из конкретно возникшей ситуации.
32. Тестирование.
Целесообразно предварительное тестирование вновь разработанной конфигурации проводить на специально собранном для этой цели полигоне на территории Исполнителя с обязательным присутствием представителей Заказчика.
В случае невозможности проведения предварительного тестирования на полигоне Исполнителя по техническим или организационным причинам, тестирование проводится на территории и оборудовании Заказчика.
В любом случае составляется и подписывается обеими сторонами акт, отражающий итоги проведенных испытаний.
На этапе тестирования конфигурация проверяется на соответствие всем пунктам ТЗ в их последней редакции. Выявляются нестыковки и отклонения в реально существующей конфигурации и требований указанных в ТЗ.
При проверке документов, необходимо заводить данные близкие к реальным, т.е. осуществлять проверку по «живым» документам. Это позволяет избежать мелких, но досадных ошибок (например: не хватает разрядности у числовых переменных, не «влезает» наименование и т.п.). Если справочник имеет несколько уровней, то нужно сразу создать группы во избежание ошибок, связанных принадлежностью элементов к группам. Если с документом, предполагается работа нескольких пользователей с разными правами, то необходимо сразу создать соответствующие наборы прав, особенно если разделение доступа производится средствами языка.
После тестирования проводится совещание с участием представителей Заказчика и Исполнителя, на котором принимаются решение о дальнейших действиях (в т.ч. по выявленным отклонениям).
33. Обучение администраторов.
Администраторы принимают активнейшее участие в тестировании разработанной конфигурации. Именно на этом этапе они получают основную часть требуемых знаний. В случае необходимости проводится дополнительное обучение администраторов силами квалифицированных специалистов внедренческой фирмы. Темы обучения, объем и форма преподаваемого материала определяется отдельно для каждого конкретного проекта.
Необходимо учитывать, что администраторы информационной базы заказчика являются очень значимыми звеньями в процессе эксплуатации системы. Значительное количество обращений пользователей на линию консультаций происходит именно из-за отсутствия у заказчика хорошо подготовленных специалистов, способных квалифицированно решать задачи ежедневного обслуживания информационной системы.
34. Обучение персонала.
Подготовку специалистов заказчика, как уже говорилось, целесообразно начинать уже на первых стадиях внедрения и вести эту работу на всех его этапах. Специализированное обучение персонала работе на разработанной конфигурации проводится квалифицированными экспертами внедренческой фирмы. Персонал должен получить все необходимые для корректной эксплуатации системы знания и навыки. Именно качественная подготовка персонала во многом определяет успех автоматизации. В некоторых случаях бывает полезным в завершении обучения проводить сертификационные экзамены.
См также рекомендации по обучению[2, раздел «Типовой набор услуг»].
35. Подготовка пользовательской документации.
Обучение пользователей не освобождает внедренцев от подготовки пользовательской документации. Эта задача начинается с описаний к справочникам и документам, которые делаются еще на этапе создания макетной конфигурации (т.е. при выполнении задачи 31). В процессе написания алгоритмов для проведения документов, эти описания пополняются, затем редактируются и собираются в один файл (документ). Файл желательно снабдить для наглядности иллюстрациями.
36. Сдача-приемка конфигурации.
Сдача-приемка конфигурации осуществляется на территории Заказчика в присутствии его представителей и представителей Исполнителя. Конфигурация проверяется на соответствие всем пунктам ТЗ. По факту сдачи-приемки составляется и подписывается соответствующий акт.
37. Опытная эксплуатация.
Опытная эксплуатация представляет собой пробную эксплуатацию системы в продолжение заранее оговоренного срока. Во время опытной эксплуатации Исполнитель обязуется обеспечить непрерывный контроль функционирования системы и в случае необходимости устранить возможные ошибки в работе конфигурации (назначается эксперт отв. за выполнение данной задачи). После проведения опытной эксплуатации составляется и подписывается соответствующий акт.
Важно понимание того, что во время опытной эксплуатации неизбежно возникновение ошибок как по вине сотрудников заказчика, отвечающих за эксплуатацию системы, так и в результате ошибок в конфигурации, не выявленных на этапе тестирования.
Изменения, вносимые в конфигурацию на этапе опытной эксплуатации, очень ответственная задача. Если конфигурация писалась коллегиально, необходимо тщательно проанализировать, не приведут ли эти изменения к ошибкам в работе документов, написанных другим исполнителем.
38. Проработка условий выполнения этапа III внедрения.
Заказчик и Исполнитель прорабатывают условия сопровождения системы. Обычно результатом проработки становится подготовка и подписание договора на абонементное обслуживание.
39. Закрытие этапа II внедрения.
По аналогии с задачами 10 и 16.
40. Заказчик идет на дальнейшее сотрудничество?
По аналогии с задачей 11.
ЭТАП III внедрения: Комплексное сопровождение внедренной системы
41. Договор на комплексное сопровождение.
Оптимальный вариант подобного договора: фиксированная сумма в месяц за оговоренные действия специалистов франчайзи по отслеживанию состояния базы, исправление своих же мелких погрешностей и ошибок пользователей, которые неизбежны на начальном этапе реальной эксплуатации системы. Исправление же ошибок, допущенных при проектировании и разработке ТЗ (а таковые нередки и, как правило, являются обоюдными), а также доработку конфигурации лучше всего приравнять к разработке (т.е. проводить по расценкам договора на внедрение). Это важный момент и он должен быть предусмотрен в договоре на сопровождение.
42. Абонементное обслуживание.
Существует две модели выполнения задачи 42.
Реактивная модель предполагает, что действия специалистов франчайзи по сопровождению системы осуществляются после возникновения проблемы.
Активная модель предполагает проведение профилактических действий, предупреждающих появление проблем, связанных с эксплуатацией информационной системы.
Естественно, вторая модель предполагает более активные действия. Поэтому такая форма абонементного обслуживания несколько дороже по стоимости. Однако, как показывает опыт, безотказная работа хорошей информационной системы с лихвой окупает все затраты на ее эксплуатацию.
43. Система сопровождения пользователей.
Определение ключевых полей
Определение ключевых полей
Выше неоднократно упоминалось понятие ключевого поля. Ключевое поле — это одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице. Если для таблицы определены ключевые поля, то Microsoft Access предотвращает дублирование или ввод пустых значений в ключевое поле. Ключевые поля используются для быстрого поиска и связи данных из разных таблиц при помощи запросов, форм и отчетов.
В Microsoft Access можно выделить три типа ключевых полей: счетчик, простой ключ и составной ключ. Рассмотрим каждый из этих типов.
Для создания ключевого поля типа Счетчик необходимо в режиме Конструктора таблиц:
-
Включить в таблицу поле счетчика.
Задать для него автоматическое увеличение на 1.
Указать это поле в качестве ключевого путем нажатия на кнопку Ключевое поле (Primary Key) на панели инструментов Конструктор таблиц (Table Design).
Для создания простого ключа достаточно иметь поле, которое содержит уникальные значения (например, коды или номера). Если выбранное поле содержит повторяющиеся или пустые значения, его нельзя определить как ключевое. Для определения записей, содержащих повторяющиеся данные, можно выполнить запрос на поиск повторяющихся записей. Если устранить повторы путем изменения значений невозможно, следует либо добавить в таблицу поле счетчика и сделать его ключевым, либо определить составной ключ.
Составной ключ необходим в случае, если невозможно гарантировать уникальность записи с помощью одного поля. Он представляет собой комбинацию нескольких полей. Для определения составного ключа необходимо:
-
Открыть таблицу в режиме Конструктора.
Выделить поля, которые необходимо определить как ключевые.
Нажать кнопку Ключевое поле (Primary Key) на панели инструментов Конструктор таблиц (Table Design).
Для составного ключа существенным может оказаться порядок образующих ключ полей. Сортировка записей осуществляется в соответствии с порядком ключевых полей в окне Конструктора таблицы. Если необходимо указать другой порядок сортировки без изменения порядка ключевых полей, то сначала нужно определить ключ, а затем нажать кнопку Индексы (Indexes) на панели инструментов Конструктор таблиц (Table Design). Затем в появившемся окне Индексы (Indexes) нужно указать другой порядок полей для индекса с именем Ключевое поле (Primary Key).
В данном случае в качестве составного ключа используются поля "Код заказа" (OrderlD) и "КодТовара" (ProductID), т. к. ни одно из этих полей в отдельности не гарантирует уникальность записи. При этом в таблице выводится не код товара, а наименование товара, т. к. поле "КодТовара" (ProductID) данной таблицы содержит подстановку из таблицы "Товары" (Products), а значения полей "КодТовара" (ProductID) этих таблиц связаны отношением "один-ко-многим" (одной записи таблицы "Товары" (Products) может соответствовать несколько записей таблицы "Заказано" (OrderDetails)). Оба поля могут содержать повторяющиеся значения. Так, один заказ может включать в себя несколько товаров, а в разные заказы могут включаться одинаковые товары. В то же время сочетание полей "КодЗаказа" (OrderlD) и "КодТовара" (ProductID) однозначно определяет каждую запись таблицы "Заказы" (OrderDetails).
Чтобы изменить ключ, необходимо:
-
Открыть таблицу в режиме Конструктора.
Выбрать имеющиеся ключевые поля.
Нажать на кнопку Ключевое поле (Primary Key), при этом кнопка должна принять положение Выкл., а из области выделения должны исчезнуть значки ключевого поля.
Выбрать поле, которое необходимо сделать ключевым.
Нажать на кнопку Ключевое поле (Primary Key). При этом в области выделения должен появиться значок ключевого поля.
Определение маски ввода
Определение маски ввода
Если свойство Формат (Format) управляет тем, как данные отображаются в поле таблицы, то свойство Маска ввода (Input Mask) позволяет контролировать ввод данных в таблицу. И не только контролировать, но и упрощать процесс ввода. Маску используют в том случае, когда вводимые данные должны содержать определенные символы в некоторых позициях вводимой строки. Самым простым и ярким примером таких данных являются номера телефонов. Маска ввода должна обеспечить возможность вводить только цифры номера, а остальные символы (скобки вокруг кода города, дефис между цифрами номера) будут добавляться автоматически. Маска задается с помощью символов, приведенных в табл. 2.12.
Определение полей При создании...
Определение полей При создании таблиц в режиме Конструктора приходится задавать имена таблиц и полей в таблицах. При этом необходимо придерживаться ряда правил.
Имена полей в таблице не должны повторяться, т. е. должны быть уникальными. Имена полей могут содержать не более 64 символов, включая пробелы.
Желательно избегать употребления имен полей, совпадающих с именами встроенных функций или свойств Microsoft Access (например, Name — имя).
Имя поля не должно начинаться с пробела или управляющего символа (коды ASCII 00-31).
Имена полей могут содержать любые символы, включая буквы, цифры, пробелы, специальные символы, за исключением точки (.), восклицательного знака (!), апострофа (') и квадратных скобок ([), (]).
Эти же правила действительны и для имен таблиц, а также других объектов Microsoft Access.
Совет
Рекомендуется не использовать очень длинные имена, т. к. они плохо запоминаются, и не включать в имена большое количество пробелов, особенно если с именами предполагается работать с помощью процедур Visual Basic for Application. Чтобы следовать этой рекомендации и при этом получать понятные имена, можно либо использовать вместо пробелов между словами знак подчеркивания (_), либо писать все слова слитно, но каждое начинать с заглавной буквы.
Текстовый (Text) — символьные или числовые данные, не требующие вычислений. Поле данного типа может содержать до 255 символов. Размер текстового поля задается с помощью свойства Размер поля (FieldSize), в котором указывается максимальное количество символов, которые могут быть введены в данное поле. При необходимости ввести строку большего размера, чем указано в данном свойстве, надо значение свойства изменить, т. к. место под дополнительные символы не резервируется. Независимо от длины текстового поля оно хранится в базе данных Access в записи переменной длины. Access не занимает память под неиспользуемую часть текстового поля в записи, что уменьшает общий размер базы данных.
Поле MEMO (MEMO) — поле MEMO предназначено для ввода текстовой информации, по объему превышающей 255 символов. Такое поле может содержать до 65 535 символов. Этот тип данных отличается от типа Текстовый (Text) тем, что в таблице хранятся не сами данные, а ссылки на блоки данных, хранящиеся отдельно. За счет этого ускоряется обработка таблиц (сортировка, поиск и т. п.). Поле типа MEMO не может быть ключевым или проиндексированным.
Совет
Не используйте поле типа MEMO, если нужно будет сортировать записи таблицы по данному полю — это невозможно. Если 255 символов не достаточно для хранения всех данных, придется разбить его на два или три текстовых поля.
Дата/Время (Date/Time) — тип для представления даты и времени. Позволяет вводить даты с 100 по 9999 год. Размер поля — 8 байтов. Даты и время хранятся в специальном фиксированном числовом формате. Дата является целой частью значения поля типа Дата/Время, а время — его дробной частью. Access предоставляет большой выбор форматов отображения даты и времени.
Денежный (Currency) — тип данных, предназначенный для хранения данных, точность представления которых колеблется от 1 до 4 десятичных знаков. Целая часть данного типа может содержать до 15 десятичных знаков.
Счетчик (AutoNumber) — поле содержит 4-байтный уникальный номер, определяемый Microsoft Access автоматически для каждой новой записи либо случайным образом, либо путем увеличения предыдущего значения на 1. Значения полей типа счетчика обновлять нельзя. Максимальное число записей в таблице с полем счетчика не должно превышать двух миллиардов.
Логический (Yes/No) — логическое поле, которое может содержать только два значения, интерпретируемых как Да/Нет, Истина/Ложь, Включено/Выключено. Поля логического типа не могут быть ключевыми, но их можно индексировать.
Внимание
Access использует величину -1 для представления значения
Истина
и величину 0 — для значения
Ложь.
Гиперссылка (Hyperlink) — дает позможность хранить в поле ссылку, с помощью которой можно ссылаться на произвольный фрагмент данных внутри файла или Web-страницы на том же компьютере, в интранет или в Интернет. Гиперссылка состоит из четырех частей: отображаемый текст, адрес (путь к файлу или странице), дополнительный адрес (положение внутри файла или страницы) и текст всплывающей подсказки. Каждая часть гиперссылки может содержать до 2048 символов. Поле типа Гиперссылка не может быть ключевым или индексированным.
В поле типа можно также выбрать значение Мастер подстановок (Lookup Wizard), который запускает Мастера подстановок (Lookup Wizard), создающего поле подстановок. Поле подстановок позволяет выбирать значение поля из списка, содержащего набор постоянных значений или значений из другой таблицы. (О поле подстановок мы подробно будем говорить позже в разд. "Использование Мастера подстановок" данной главы.)
Как только вы выбираете тип данных для поля, так на нижней панели окна отображается список свойств этого поля. Данный список зависит от типа поля. Для того чтобы просмотреть или изменить свойства конкретного поля таблицы необходимо:
-
Выделить нужное поле таблицы (то есть установить курсор в строку с именем поля) в окне Конструктора.
Раскрыть вкладку Общие (General) для просмотра общих свойств поля или вкладку Подстановка (Lookup) для просмотра параметров подстановки.
Основные принципы работы компоненты
Общие принципы
Принципы разрешения спорных ситуаций
В новой версии Microsoft Access существуют четыре режима работы с таблицами: режим Таблицы (Datasheet View), режим Конструктора (Design View), режим Сводной таблицы (PivotTable View) и режим Сводной диаграммы (PivotChart View).
В режиме Таблицы осуществляется работа с данными, находящимися в таблице: просмотр, редактирование, добавление, сортировка и т. п. В режиме Конструктора создается или модифицируется структура таблицы, т. е. задаются имена полей таблицы и их типы, поля описываются, задаются их свойства. В режимах Сводной таблицы и Сводной диаграммы удобно выполнять анализ данных, динамически изменяя способы их представления. Существует также дополнительный режим — режим Предварительного просмотра, который позволяет увидеть расположение данных на листе перед осуществлением печати таблицы.
Для быстрого перехода из одного режима в другой служит кнопка Вид (View) на панелях инструментов Таблица в режиме таблицы (Table Datasheet), Конструктор таблиц (Table Design), Сводная таблица (PivotTable) и Сводная диаграмма (PivotChart). Чтобы перейти из режима в режим, достаточно нажать эту кнопку.
Открыть таблицу в режиме Таблицы можно несколькими способами:
дважды щелкнуть мышью на имени таблицы в списке таблиц в окне базы данных;
выделить таблицу в списке таблиц в окне базы данных и нажать кнопку Открыть (Open) в верхней части окна базы данных;
щелкнуть правой кнопкой мыши на имени таблицы и из контекстного меню выбрать команду Открыть (Open).
В любом случае на экране появится окно с содержимым таблицы (рис. 2.1).
Освоение и обучение
| Интеграционный … |
| 2.4.6 | 02-БО-060 | Построить информационную модель будущего бизнеса (в случае проведения преобразований бизнес-процессов) | Информационная … |
| 2.4.7 | 02-БО-070 | Провести анализ выполнения требований к отчетности | Главный журнал отчетов |
| 2.4.8 | 02-БО-080 | Протестировать решения по отображению бизнеса | Протестированные … |
| 2.4.9 | 02-БО-090 | Подтвердить интегрированные решения по отображению бизнеса | Обяз. | Док. | Подтвержденные … |
| 2.5 | 02-ТА | Построение технической архитектуры |
| 2.5.1 | 02-ТА-040 | Определить архитектуру приложения | Обяз. | Архитектура приложения |
| 2.5,2 | 02-ТА-050 | Определить стратегию обеспечения работоспособности приложения | Обяз. | Стратегия … |
| 2.5.3 | 02-ТА-060 | Определить стратегию отчетности и доступа к информации | Стратегия … |
| 2.5.4 | 02-ТА-070 | Провести коррекцию концептуальной архитектуры | Концептуальная … |
| 2.6 | 02-ПМ | Создание программных модулей |
| 2.6.1 | 02-ПМ-020 | Оценить целесообразность расширений | Обяз. | Оценка целесообразности расширения |
| 2.7 | 02-ДО | Документирование |
| 1.12.5 | 01-УК-050 | Комплексная оценка качества | Обяз. | Док. | Отчет о качестве |
| 1.12.6 | 01-УФ-060 | Провести аудит ключевых результатов | Обяз. | Док. | Аудированные результаты |
| 1.12.7 | 01-ФЗ-КОН | Закончить процесс завершение фазы |
| 2 | 02 | Анализ и оценка |
| 2.1 | 02-ФП | Планирование фазы |
| 2.1.1 | 02-ФП-НАЧ | Начать планирование фазы |
| 2.1.2 | 02-ФП-ИНД | Провести обзор и ревизию планов | Обяз. | Док. | Скорректированные планы |
| 2.1.3 | 02-ФП-КОН | Закончить планирование фазы |
| 2.2 | 02-БП | Моделирование бизнес-процессов |
| 2.2.1 | 02-ФВ-НАЧ | Начать выполнение фазы |
| 2.2.2 | 02-БП-080 | Разработать модель будущих процессов (в случае проведения преобразований) |
| Модель будущих процессов |
| 2.3 | 02-БТ | Определение бизнес-требований |
| 2.3.1 | 02-БТ-030 | Составить итоговый документ по процессам и их отображению | Обяз. | Док. | Итоговый … |
| 2.3.2 | 02-БТ-040 | Собрать показатели информационной деятельности предприятия (типы транзакций, интенсивность потоков, объемы хранения данных) | Показатели деятельности |
| 2.3.3 | 02-БТ-050 | Собрать бизнес-требования | Обяз. | Док. | Сценарии бизнес-требований |
| 2.3.4 | 02-БТ-060 | Определить требования к аудиту и контролю | Требования … |
| 2.3.5 | 02-БТ-070 | Определить требования к условиям функционирования бизнеса | Обяз. | Док. | Требования … |
| 2.3.6 | 02-БТ-080 | Определить требования к отчетности и доступу к информации | Обяз. | Док. | Требования … |
| 2.12.5 | 02-УК-050 | Комплексная оценка качества | Обяз. | Док. | Отчет о качестве |
| 2.12.6 | 02-УФ-060 | Провести аудит ключевых результатов | Обяз. | Док. | Аудированные результаты |
| 2.12.7 | 02-ФЗ-КОН | Закончить процесс завершение фазы |
| 3 | 03 | Техническое проектирование |
| 3.1 | 03-ФП | Планирование фазы |
| 3.1.1 | 03-ФП-НАЧ | Начать планирование фазы |
| 3.1.2 | 03-ФП-ИНД | Провести обзор и ревизию планов | Обяз. | Док. | Скорректированные планы |
| 3.1.3 | 03-ФП-КОН | Закончить планирование фазы |
| 3.2 | 03-БП | Моделирование бизнес-процессов |
| 32.1 | 03-ФВ-НАЧ | Начать выполнение фазы |
| 3.2.2 | 03-БП-090 | Документировать бизнес-процедуры | Обяз. | ?Док | Документированные бизнес-процедуры |
| 3.3 | 03-БО | Отображение бизнес-требований |
| 3.3.1 | 03-БО-100 | Определить настроечные параметры | Обяэ. | Описание … |
| 3.3.2 | 03-БО-110 | Подготовить спецификации информационной защиты | Обяз. | Док. | Спецификации … |
| 3.4 | 03-ТА | Построение технической архитектуры |
| 3.4.1 | 03-ТА-080 | Определить архитектуру системы информационной |
| Архитектура … |
| 3.5 | 03-ПМ | Создание программных модулей |
| 3.5.1 | 03-ПМ-030 | Определить стандарты проектирования | Стандарты … |
| 3.5.2 | 03-ПМ-040 | Определить стандарты реализации | Стандарты … |
| 3.5.3 | 03-ПМ-050 | Выполнить функциональное проектирование расширений | Обяз. | Функциональные проекты расширений |
| 3.5.4 | 03-ПМ-060 | Выполнить проектирование расширений базы данных | Обяг | 1. | Проект … |
| 3.5.5 | 03-ПМ-070 | Подготовить технические спецификации на модули расширения | Обя; | i. | Технические … |
| 3.5.6 | 03-ПМ-080 | Провести обзор функциональных и технических решений | Обя: | i. | Утвержденные функциональные и … |
| 3.6 | 03-ПД | Преобразование данных |
| 3.6.1 | 03-ПД-020 | Определить стандарты преобразования данных | Стандарты … |
| 3.6.2 | 03-ПД-030 | Подготовить среду преобразования данных | Обя; | i. | Среда … |
| 3.6.3 | 03-ПД-040 | Построить отображение данных для проведения преобразования | Обя: | i. | Схема отображения … |
| 3.6.4 | 03-ПД-050 | Определить ручные процедуры преобразования данных | Обя; | i. | Описание … |
| 3.6.5 | 03-ПД-060 | Разработать программы преобразования данных | Обя: | i. | Программы … |
| 3.6.6 | 03-ПД-070 | Подготовить планы тестирования преобразования данных | Обяг | i. | Планы … |
| 3.7 | 03-ТС | Тестирование |
| 3.7.1 | 03-ТС-020 | Подготовить методики автономного тестирования | Обя: | i. | Описание … |
| 3.7.2 | 03-ТС-030 | Подготовить описания (скрипты) тестов межмодульны: связей | хОбя: | ). | Описание … |
| 3.7.3 | 03-ТС-040 | Подготовить системных тестов | Описание … |
| 3.7.4 | 03-ТС-050 | Подготовить описания тестов интеграции с внешними приложениями | Описание … |
| 3.8 | 03-ТР | Тестирование рабочих характеристик |
| 3.8.1 | 03-ТР-040 | Подготовить описания тестов рабочих характеристик | Описание … |
| 3.8.2 | 03-ТР-050 | Разработать транзакционные программы тестирования рабочих характеристик |
| Транзакционные … |
| 3.8.3 | 03-ТР-060 | Подготовить данные для тестирования рабочих характеристик | Обяз. | Данные … |
| 3.8.4 | 03-ТР-070 | Разработать программы загрузки тестовых данных | Обяз. | Программы … |
| 3.9 | 03-ОБ | Освоение и обучение | Освоение и обучение |
| 3-9.1 | 03-ОБ-100 | Определить влияние изменений бизнес-процессов на организацию | Обяз. | Оценка влияния … |
| 3.9.2 | 03-ОБ-110 | Скорректировать средства и методы поддержки эффективной работы персонала | Обяз. | Средства … |
| 3.9.3 | 03-ОБ-120 | Наладить работу ИТ-подразделений в новых условиях | Обяз. | Подготовленные ИТ-подразделения … |
| 3.9.4 | 03-ОБ-130 | Провести анализ потребностей пользователей в обучении | Анализ … |
| 3.9,5 | 03-ОБ-140 | Составить план обучения пользователей | Обяз. | План … |
| 3.9.6. | 03-ФВ-КОН | Закончить выполнение фазы |
| 3.10 | 03-tPK | Контроль фазы |
| 3.10.1 | 03-ФК-КАЧ | Начать контроль выполнения фазы |
| 3.10.2 | 03-ФК-ИНД | Контролировать выполнение фазы | Контролируемый ход выполнения проекта |
| 3.10.3 | 03-ФК-РЕЗ | Контролировать неразмещенные резервы |
| 3.10.4 | 03-ФК-КОН | Закончить контроль выполнения фазы |
| 3.11 | 03-ФЗ | Завершение фазы |
| 3.11;1 | 03-ФЗ-НАЧ | Начать процесс завершения фазы |
| 3.11:2 | 03-УО-080 | Обеспечть приемку результатов клиентом | Обяз. | Док. | Акты приемки-передачи результатов |
| 3.11,3 | 03-УС-080 | Высвободить персонал | Высвобожденный … |
| 3.11.4 | 03-УС-090 | Высвободить физические ресурсы | Высвобожденные … |
| 3.11.5 | 03-УК-050 | Комплексная оценка качества | Обяз. | Док. | Отчет о качестве |
| 3.11.6 | 03-УФ-060 | Провести аудит ключевых результатов | Обяз. | Док. | Аудированные результаты |
| 3.11.7 | 03-ФЗ-КОН | Закончить процесс завершения фазы |
| 4 | 04 | Рабочее проектирование |
| 4.1 | 04-ФП |
Отображение подчиненных таблиц
Отображение подчиненных таблиц
В Microsoft Access 2002 присутствует возможность отображения нескольких связанных таблиц в окне главной таблицы. Рассмотрим возможности отображения на примере таблиц "Типы" (Categories), "Товары" (Products) и "Заказано" (Order Details) базы данных "Борей". На рис. 2.41 изображена схема данных указанной базы. На схеме видно, что таблицы "Типы" (Categories) и "Товары" (Products) связаны отношением "один-ко-многим", т. е. одной записи в таблице "Типы" (Categories) может соответствовать множество записей таблицы "Товары" (Products). Таблица "Товары" (Products) связана с таблицей "Заказано" (Order Details) тоже отношением "один-ко-многим".
Отраслевые конфигурации
Прежде всего, попробуем определить, что же такое «отраслевая конфигурация». На мой взгляд, будет уместным такое определение этого продукта:
Отраслевая конфигурация (или типовое отраслевое решение - TOP) – это конфигурация, специально написанная для удовлетворения потребностей учета в определенной сфере деятельности, учитывающая специфику учета отрасли в целом, и не отражающей специфику какого-либо конкретного предприятия.
Как следует из определения, основное предназначение ТОРа – учет отраслевой специфики. Из этого следует, что ТОР необходимо выбирать тогда, когда у клиента есть четкая отраслевая специфика (например, торговля медикаментами или розничная торговля с применением различного торгового оборудования). На данный момент (15/02/2000 г.) существует большое количество (только в прайс-листе фирмы «1С» их насчитывается 27) отраслевых решений выпущенных различными фирмами-франчайзи и самой фирмой «1С». Эти решения охватывают достаточно большой спектр отраслей, начиная с расчета заработной платы для «1С: Бухгалтерии 6.0» и заканчивая реализацией интернет-магазина для «1С:Предприятия 7.5/7.7». Полный список отраслевых решений, сертифицированных фирмой «1С» можно найти в [2].
Перечислим основные преимущества ТОР:
приобретается не только готовая конфигурация, но и определенная система знаний по тому, как вести автоматизированный учет в данной отрасли;
проделана большая работа по формированию системы учета, отвечающая заданной отраслевой специфики;
затраты на доводку ТОР меньше (а иногда значительно), чем затраты на доработку типовой конфигурации фирмы «1С».
Резюме. ТОР подходят для фирм, которые имеют выраженную отраслевую специфику. В этом случае разумно подобрать для клиента готовый ТОР (если он есть) и затем доработать его. Компьютерная сеть может варьироваться от простого компьютера до мощной сети с несколькими серверами. Возможно использование SQL-серверной версии платформы «1С:Предприятие».
Партнеры компании
Практические цели разработки методологии в "наибольшей степени затрагивают партнеров компании «"1С"». Ниже приводится их краткое описание и типизация.
Печать таблицы
Печать таблицы
Самым простым способом вывода таблицы на печать является использование кнопки Печать (Print) на панели инструментов База данных (Database). Чтобы вывести таблицу на печать таким способом, необходимо:
-
Выделить таблицу в окне базы данных.
Нажать кнопку Печать (Print) на панели инструментов База данных (Database).
Для того чтобы иметь возможность изменять параметры печати, необходимо воспользоваться возможностями печати из режима Таблицы (рис. 2.52).
Для этого нужно:
-
Открыть таблицу в режиме Таблицы.
Выбрать в меню Файл (File) команду Печать (Print).
В окне Печать (Print) (рис. 2.50), в блоке Принтер (Printer), в поле имя (Name) выбрать принтер, на котором предполагается печатать таблицу.
При необходимости нажать кнопку Свойства (Properties) для получения доступа к свойствам принтера.
При необходимости установить флажок печать в файл (Print to file) для создания файла на диске.
Письменное обращение
К письменному обращению мы относим письмо по электронной почте. Такое письмо может возникнуть в нескольких случаях:
по адресу на Вашей визитной карточке (подразумевается наличие адреса электронной почты на визитных карточках сотрудников);
после посещения Вашего Web-сайта. В этом случае письмо придет либо на обобщенный адрес фирмы (например, таким адресом у «IC-Papyca» является адрес lc@rarus.ru), либо на адрес сотрудника (или подразделения), отвечающего за то или иное направление деятельности;
предложение участия в тендере на автоматизацию какого-либо предприятия;
разрешение какой-либо проблемы.
Письмо сотруднику
Отвечать на письма необходимо всегда. При ответе на письмо дует всегда подписываться, причем из Вашей подписи люди могли четко представить, как связаны отвечающий сотрудник и тема данного вопроса. Например, если приходит вопрос по системе «1С-Рарус:Фармацевт», то в качестве подписи необходимо написать «С уважением, Плякин Александр, разработчик системы».
Планирование
| пп-УО-010 | Установить область рассмотрения, цели и подход к реализации проекта | Начальная версия плана управления проектом |
| пп-УО-020 | Определить стратегию, стандарты и процедуры контроля и отчетности | Стратегии, … |
| пп-УО-030 | Составить планы управления | План управления проектом (суммирует результаты предыдущих задач) |
| nn-ФК |
| пп-УР-010 | Определить стратегию, стандарты и процедуры управления работами | Стратегия, стандарты и процедуры управления работами |
| пп-УР-020 | Составить рабочий план проекта | Рабочий план проекта |
| nn-УР-ОЗО | Составить финансовый план проекта | Финансовый план проекта |
| nn-ФК |
| пп-УС-010 | Определить стратегию, стандарты и процедуры управления ресурсами | Стратегию, стандарты и процедуры управления ресурсами |
| пп-УС-020 | Составить организационно-кадровый план | Организационно-кадровый план |
| пп-УС-025 | Создать руководство по административным процедурам для членов группы проекта | Руководство по административным процедурам |
| nn-УС-ОЗО | Создать организационную структуру проекта | Укомплектованная кадрами организационная структура проекта |
| ПП-УС-040 | Принять план физических ресурсов (необходимых сверх существующей инфраструктуры) | План физических ресурсов |
| ПП-УС-050 | Подготовить инфраструктуру проекта | Готовая инфраструктура проекта |
| nn-ФК |
| пп-УК-010 | Определить стратегию, стандарты и процедуры управления качеством | Стратегия, стандарты и процедуры управления качеством |
| nn-ФК |
| пп-УФ-010 | Определить стратегию, стандарты и процедуры управления конфигурацией | Стратегия, … |
| пп-ФК |
Планирование фазы
| 4.1.1 | 04-ФП-НАЧ | Начать планирование фазы |
| 4.1.2 | 04-ФП-ИНД | Провести обзор и ревизию планов | Обяз. | Док. | Скорректированные планы |
| 4.1.3 | 04-ФП-КОН | Закончить планирование фазы |
| 4.2 | 04-ТА | Построение технической архитектуры |
| 4.2.1 | 04-ФВ-КАЧ | Начать выполнение фазы |
| 4.2.2 | 04-ТА-090 | Определить архитектуру серверов базы данных | Архитектура серверов базы данных |
| 4.2.3 | 04-ТА-100 | Определить дополнительные подсистемы на уровне архитектуры | Предложения по дополнительным … |
| 4.2.4 | 04-ТА-110 | Составить план обеспечения производительности системы | План … |
| 4.2.5 | 04-ТА-120 | Определить платформу и сетевую архитектуру | Обяз. | Платформа и … |
| 4.2.6 | 04-ТА-130 | Составить план развертывания системы | Обяз. | Док. | План … |
| 4.2.7 | 04-ТА-140 | Оценить риски недостижения требуемых характеристик | :0бяз. | Оценка рисков … |
| 4.2.8 | 04-ТА-150 | Определить процедуры управления системой | Обяз. | Процедуры … |
| 4.3 | 04-ПМ | Создание программных модулей |
| 4.3.1 | 04-ПМ-090 | Подготовить среду разработки | Обяз. | Среда … |
| 4.3.2 | 04-ПМ-100 | Создать расширения базы данных | Обяз. | Пользовательские объекты базы данных |
| 4.33 | 04-ПМ-110 | Создать модули расширения функциональности | Обяз. | Модули … |
| 4.3.4 | 04-ПМ-120 | Создать процедуры установки | Процедуры … |
| 4.4 | 04-ПД | Преобразование данных |
| 4.4.1 | 04-ПД-080 | Разработать программы преобразования данных | Обяз. | Программы … |
| 4.4.2 | 04-ПД-090 | Выполнить автономные тесты программ преобразования данных | Обяз. | Автономно протестированные … |
| 4.4.3 | 04-ПД-100 | Выполнить сквозные тесты преобразования данных | Обяз. | Прошедшие сквозные тесты программы … |
| 4.4.4 | 04-ПД-110 | Выполнить тесты правильной работы с преобразованными данными | Обяз. | Прошедшие заключительные тесты программы … |
| 4.5 | 04-ДО | Документирование |
| 4.5.1 | 04-ДО-060 | Выпустить справочное руководство пользователя | Обяз. | Док. | Справочное … |
| 4.5.2 | 04-ДО-070 | Выпустить руководство пользователя | Руководство … |
| 4.5.3 | 04-ДО-080 | Выпустить справочное техническое руководство | Справочное … |
| 4.5.4 | 04-ДО-090 | Выпустить руководство по управлению системой | Руководство … |
| 4.6 | 04-ТС | Тестирование |
| 4.6.1 | 04-ТС-060 | Подготовить среду тестирования | Среда … |
| 4.6.2 | 04-ТС-070 | Выполнить автономные тесты | Обяз. | Модули, прошедшие автономные тесты |
| 4.6.3 | 04-ТС-080 | Выполнить тесты межмодульных связей | Обяз. | Модули, прошедшие тесты связей |
| 4.6.4 | 04-ТС-090 | Выполнить тест установки | Протестированные процедуры установки |
| 4.6.5 | 04-ТС-100 | Отобрать ключевых пользователей для участия в тестировании | Обяз. | Ключевые … |
| 4.6.6 | 04-ТС-110 | Провести общее тестирование системы | Обяз. | Док | общее тестирование системы |
| 4.6.7 | 04-ТС-120 | Выполнить тесты интеграции с внешними приложениями | Система, прошедшая тесты интеграции с … |
| 4.7 | 04-ТР | Тестирование рабочих характеристик |
| 4.7.1 | 04-ТР-080 | Разработать транзакционные программы для тестирования рабочих характеристик | Обяз. | Транзакционные … |
| 4.7.2 | 04-ТР-090 | Разработать программы загрузки тестовых данных | Программы … |
| 4.7.3 | 04-ТР-100 | Создать базу данных для тестирования рабочих характеристик | База данных … |
| 4.7.4 | 04-ТР-110 | Создать среду для тестирования рабочих характеристик | Среда … |
| 4.7.5 | 04-ТР-120 | Провести тестирование рабочих характеристик | Обяз. | Результаты тестирования … |
| 4.7.6 | 04-ТР-130 | Подготовить отчет о результатах тестирования рабочих характеристик | Обяз. | Док. | Отчет … |
| 4.8 | 04-ОБ | Освоение и обучение | Освоение и обучение |
| 4.8.1 | 04-ОБ-150 | Подготовить средства и методы обучения |
| Обяз. | Средства и … |
| 4.8.2 | 04-06-160 | Подготовить среду обучения | Обяз. | Среда … |
| 4.9 | 04-ПЭ | Переход к промышленной эксплуатации |
| 4.9.1 | 04-ПЭ-020 | Подготовить проект создания инфраструктуры поддержки | Обяз. | Проект … |
| 4.9.2 | 04-ПЭ-030 | Составить план перехода и обеспечения непрерывности бизнеса | Обяз. | План … |
| 4.9.3 | 04-ФВ-КОН | Закончить выполнение фазы |
| 4.10 | 04-ФК | Контроль фазы |
| 4.10.1 | 04-ФК-НАЧ | Начать контроль выполнения фазы |
| 4.10.2 | 04-ФК-ИНД | Контролировать выполнение фазы | Контролируемый ход выполнения проекта |
| 4.10.3 | 04-фк-рез | Контролировать неразмещенные резервы |
| 4.10.4 | 04-ФК-КОК | Закончить контроль выполнения фазы |
| 4.11 | 04-ФЗ | Завершение фазы |
| 4.11.1 | 04-ФЗ-НАЧ | Начать процесс завершения фазы |
| 4.11.2 | 04-УО-080 | Обеспечить приемку результатов клиентом | Обяз. | Док. | Акты приемки-передачи результатов |
| 4.11.3 | 04-УС-080 | Высвободить персонал | Высвобожденный … |
| 4.11.4 | 04-УС-090 | Высвободить физические ресурсы | Высвобожденные … |
| 4.11.5 | 04-УК-050 | Комплексная оценка качества | Обяз. | Док. | Отчет о качестве |
| 4.11.6 | 04-УФ-060 | Провести аудит ключевых результатов | Обяз. | Док. | Аудированные результаты |
| 4.11.7 | 04-ФЗ-КОН | Закончить процесс завершение фазы |
| 5 | 05 | Ввод в эксплуатацию |
| 5.1 | 05-ФП | Планирование фазы |
| 5.1.1 | 05-ФП-НАЧ | Начать планирование фазы |
| 5.1.2 | 05-ФП-ИНД | Провести обзор и ревизию планов | Обяз. | Док. | Скорректированные планы |
| 5.1.3 | 05-ФП-КОН | Закончить планирование фазы |
| 5.2 | 05-ПД | Преобразование данных |
| 5.2.1 | 05-ФВ-НАЧ | Начать выполнение фазы |
| 5.2.2 | 05-ПД-120 | Установить программы преобразования данных |
| Установленные … |
| 5.2.3 | 05-ПД-130 | Конвертировать и верифицировать данные | Обяз. | Конвертированные … |
| 5.3 | 05-ТС | Тестирование |
| 5.3.1 | 05-ТС^ЗО | Выполнить приемочные тесты | Обяз. | Док. | Результаты приемочных тестов |
| 5.4 | 05-ОБ | Освоение и обучение | Освоение и обучение |
| 5.4.1 | 05-ОБ-170 | Провести обучение пользователей | Обяз. | Обученные пользователи |
| 5.5 | 05-ПЭ | Переход к промышленной эксплуатации |
| 5.5.1 | 05-ПЭ-040 | Подготовить среду промышленной эксплуатации | Обяз. | Среда … |
| 5.5.2 | 05-ПЭ-050 | Установить прикладные программы | Обяз. | Установленные … |
| 5.5.3 | 05-ПЭ-060 | Создать инфраструктуру поддержки | Обяз. | Инфраструктура … |
| 5.5.4 | 05-ПЭ-070 | Проверить готовность к промышленной эксплуатации | Обяз. | Готовая к … |
| 5.5.5 | 05-ПЭ-080 | Начать промышленную эксплуатацию | Обяз. | Система в промышленной эксплуатации |
| 5.5.6 | 05-ФВ-КОН | Закончить выполнение фазы |
| 5.6 | 05-ФК | Контроль фазы |
| 5.6.1 | 05-ФК-НАЧ | Начать контроль выполнения фазы |
| 5.6.2 | 05-ФК-ИНД | Контролировать выполнение фазы | Контролируемый ход выполнения проекта |
| 5.6.3 | 05-ФК-РЕЗ | Контролировать неразмещенные резервы |
| 5.6.4 | 05-ФК-КОН | Закончить контроль выполнения фазы |
| 5.7 | 05-ФЗ | Завершение фазы |
| 5.7.1 | 05-ФЗ-НАЧ | Начать процесс завершения фазы |
| 5.7.2 | 05-УО-080 | Обеспечть приемку результатов клиентом | Обяз. | Док. | Акты приемки-передачи результатов |
| 5.7.3 | 05-УС-080 | Высвободить персонал | Высвобожденный … |
| 5.7.4 | 05-УС-090 | Высвободить физические ресурсы | Высвобожденные … |
| 5.7.5 | 05-УК-050 | Комплексная оценка качества | Обяз. | Док. | Отчет о качестве |
| 5.7.6 | 05-УФ-060 | Провести аудит ключевых результатов | Обяз. | Док. | Аудированные результаты |
| 5.7.7 |
| 05-ФЗ-КОН | Закончить процесс завершение фазы |
| 6 | 06 | Промышленная эксплуатация |
| 6.1 | 06-ФП | Планирование фазы |
| 6.1.1 | 06-ФП-НАЧ | Начать планирование фазы |
| 6.1.2 | 06-ФП-ИНД | Провести обзор и ревизию планов | Обяз. | Док. | Скорректированные планы |
| 6.1.3 | 06-ФП-КОН | Закончить планирование фазы |
| 6.2 | 06-ОБ | Освоение и обучение | Освоение и обучение |
| 6.2.1 | 06-ФВ-НАЧ | Начать выполнение фазы |
| 6.2.2 | 06-ОБ-180 | Провести оценку эффективности | Оценка эффективности |
| 6.3 | 06-ПЭ | Переход к промышленной эксплуатации |
| 6.3.1 | 06-ПЭ-090 | Измерить рабочие характеристики | Обяз. | Оценка рабочих характеристик |
| 6.3.2 | 06-ПЭ-100 | Обеспечить сопровождение системы | Обяз. | Среда сопровождения системы |
| 6.3.3 | 06-ПЭ-110 | Внести улучшения в систему | Обяз. | Улучшенная система и среда эксплуатации |
| 6.3.4 | 06-ПЭ-120 | Вывести из эксплуатации прежнюю систему | Списанная прежняя система |
| 6.3.5 | 06-ПЭ-130 | Рассмотреть направления совершенствования бизнес-процессов | Рекомендации по совершенствованию … |
| 6.3.6 | 06-ПЭ-140 | Рассмотреть направления развития информационной системы | Рекомендации по направлениям … |
| 6.3.7 | 06-ФВ-КОН | Закончить выполнение фазы |
| 6.4 | 06.ФК | Контроль фазы |
| 6.4.1 | 06-ФК-НАЧ | Начать контроль выполнения фазы |
| 6.4.2 | 06-ФК-ИНД | Контролировать выполнение фазы | Контролируемый ход выполнения проекта |
| 6,4.3 | 06-ФК-РЕЗ | Контролировать неразмещенные резервы |
| 6.4.4 | 06-ФК-КОН | Закончить контроль выполнения фазы |
| 6.5 | 06-ПЗ | Завершение проекта |
| 6.5.1 | 06-ПЗ-НАЧ | Начать процесс завершения проекта |
| 6.5.2 | 06-УО-080 | Обеспечть приемку результатов клиентом |
| Обяз. | Док. | Акты приемки-передачи результатов |
| 6.5.3 | 06-УС-080 | Высвободить персонал | Высвобожденный … |
| 6.5.4 | 06-УС-090 | Высвободить физические ресурсы | Высвобожденные … |
| 6.5.5 | 06-УК-050 | Комплексная оценка качества | Обяз. | Док. | Отчет о качестве |
| 6.5.6 | 06-УФ-060 | Провести аудит ключевых результатов | Обяз. | Док. | Аудированные результаты |
| 6.5.7 | 06-УФ-070 | Завершение управления конфигурацией и передача соответствующих функций клиенту | Работоспособная система управления конфигураций, переданная … |
| 6.5.8 | 06-ПЗ-КОН | Закончить процесс завершение проекта |
This site is hosted for FREE on VirtualAve -- yours can be, too! Click here for more information.
По договору
Сопровождение по договору. В этом случае клиент заключает с фирмой-франчайзи договор, по которому обязуется платить ей каждый месяц фиксированную сумму, в рамках которой сотрудники фирмы-франчайзи приезжают к клиенту определенное число раз в месяц и проводят закрепленные договором регламентные работы.
При этом фирма-клиент не имеет права обслуживать свою систему силами третьих лиц или организаций (даже собственных IT-специалистов). В случае возникновения нештатной ситуации фирма-франчайзи гарантирует выезд сотрудника в течение фиксированного отрезка времени (например, 4 часа).
Если в процессе обслуживания возникают дополнительные (по отношению к оговоренным в договоре) работы, то они оплачиваются по текущим ставкам фирмы-франчайзи.
Резюме. Данный метод обслуживания подразумевает абонентскую плату, регулярное появление сотрудника у клиента для проведения. регламентных работ, фиксированное время максимального отклика и дополнительную оплату за дополнительные услуги. Хорошо использовать в случае, если имеется специальное подразделение, которое занимается такого рода работами.
По вызову
Данный метод характеризуется тем, что сопровождение заказчика выполняется по принципу «первый свободный сотрудник едет к клиенту», т.е. оказывается сотрудниками, а не службой поддержки.
Такой режим более устраивает клиента по денежным затратам (он платит только за реальное рабочее время специалиста и причем только тогда, когда это нужно), но не устраивает по двум другим параметрам: скорости реакции и частой сменой специалистов. Однако многие вопросы можно решить по телефону и нет необходимости посылать туда сотрудника.
Фирме-франчайзи следует держать в офисе, по крайней мере, по одному сотруднику каждого направления для выполнения такого рода сопровождения.
Резюме. Такое сопровождение дает клиент меньше гарантий, но позволяет ему расходовать средства более экономно. Обратной стороной медали является менее предсказуемый график работы сотрудников Вашей фирмы. Метод хорошо применим при длительном сопровождении качественно обслуженных клиентов.
Почему SQL "тормозит"?
В последнее время в коференции fido.ru.1csoft стали появляться вопросы по клиент-серверным версиям (SQL) программ фирмы "1С". Аналогичные вопросы поступают к нам и по электронной почте и по телефону от клиентов нашей компании (Альтер Лого). Судя по содержанию этих вопросов (а также по содержанию ответов на них в фидошной конференции) могу с прискорбием констатировать, что люди, занимающиеся внедрением и эксплуатацией программных продуктов "1С" имеют весьма смутное представление о том, что такое клиент-серверная система, для чего она вообще нужна, как она работает и чего от нее можно и нужно ожидать, а чего нельзя.
Мимо такого непонимания я пройти спокойно не могу, поэтому беру на себя труд по сочинению этого текста, который, как я надеюсь, поможет многим из разработчиков и пользователей понять, нужен ли им SQL-продукт или нет.
Итак, первое, что необходимо понять и запомнить: SQL-системы не предназначены для ускорения выполнения выборок и печати отчетов. Если Вы ожидаете, что установив "1C-Торговлю для SQL" Вы ускорите работу своей системы, то Вы глубоко заблуждаетесь. Не будет она работать быстрее. Поэтому всякие разговоры о том, что "…SQL-Торговля - это тормоз…" абсолютно не имеют смысла. Несколько лет назад журнал PC Magazine проводил сравнительный анализ (в том числе и по быстродействию) систем управления базами данных, построенных на основе обычных файл серверов и с использованием клиент-серверных (SQL) систем. Естественно, условия испытаний по возможности были нивелированы, т.е. применялись одинаковые объемы баз данных, одинаковые их структуры, один и тот же компьютер в качестве сервера, одинаковое количество рабочих станций и т.д. Если мне не изменяет память, из клиент-серверных систем были испытаны Oracle, Interbase, Informix, Gupta и самый дешевый в то время Watcom SQL Server. Во всех случаях, средняя скорость выполнения запросов в SQL-системах была ниже, чем у файл-серверной системы (сейчас об этом эффекте можно прочесть в любой серьезной книге по SQL ). Испытатели не были удивлены полученным эффектом, поскольку были людьми грамотными и понимали причину такого поведения SQL-систем при заданных условиях эксперимента. Ведь задачей эксперимента было сравнение быстродействия двух видов систем и поэтому были выбраны условия, позволяющие произвести это сравнение. В частности для тестов использовались базы данных объемом 1.5-2Гб. Ведь если бы исследователи взялись проводить испытания, используя базы данных на порядок большего размера, то им просто не с чем было бы сравнивать SQL-варианты, поскольку обычная файл-серверная система на таких объемах информации просто заткнулась бы. Вот в этом то и состоит основное отличие и достоинство клиент-серверных систем: они будут работать со вполне приемлемой скоростью с базами данных такого объема, с которыми файл-серверная система работать просто не сможет ("не сможет" в том смысле, что ее функциональность, в том числе и быстродействие, станут неприемлемы для коммерческих приложений).
Посмотрите на обычный сетевой вариант 1С-Торговли. Она реализована на файл-серверном принципе, т.е. обработка данных ведется рабочей станцией, а сервер служит просто как дополнительное, доступное всем пользователям дисковое устройство. Это означает, что при выполнении задачи (например при сборке отчета) ВСЯ база данных (или значительная ее часть) прокачивается по сети на рабочую станцию и там обрабатывается процессором рабочей станции. Быстродействие такой системы зависит от быстродействия диска сервера, скорости передачи данных по сети, мощности процессора рабочей станции, объема ее ОЗУ и некоторых других факторов. Центральный процессор сервера играет второстепенную роль и должен просто обеспечивать передачу потока данных с сетевого канала на диск и обратно, по возможности не внося замедления в этот процесс. Главным в таком подходе является то, что практически вся база данных перегоняется по сети на рабочую станцию для последующей обработки. Если несколько станций одновременно выполняют сборку отчетов, то всем им закачивается база данных и естественно система "тормозит". Когда выполняются менее накладные операции, типа ввода нового документа, то объем перекачки данных значительно меньше, правда в реальности ввод документа как правило сопровождается поиском клиента в справочнике, вычислением задолженности клиента и т.п., что в свою очередь порождает перекачку большого количества информации с диска сервера на рабочую станцию. Не следует также забывать о необходимости синхронизации доступа рабочих станций к данным. Поскольку вся обработка ведется на уровне рабочих станций, а файл-сервер просто играет роль разделяемого дискового устройства, задачи синхронизации решаются в таких системах с помощью организации различных файлов блокировок (на диске файл-сервера) в которые каждая рабочая станция записывает информацию о данных, которые она модифицирует в данный момент, а при попытке считать данные проверяет не заняты ли эти данные другой рабочей станцией. Несмотря на ряд недостатков ("висячие" блокировки при аварийном выключении рабочих станций, "торможение" всей системы при модификации большого числа записей), способ вполне работоспособен.
Скорость работы такой системы прямо связана с объемом обрабатываемой базы данных. Они начинают ощутимо "тормозить", когда база данных достигает объема свыше 200-300Мб и при приближении к 1Гб практически просто перестает работать. Цифры конечно приблизительные и зависят от используемого программного обеспечения и формата базы данных. Например, при использовании формата таблиц базы данных Paradox торможение наступает значительно позже, чем при использовании формата DBase. Когда "торможение" ощутимо дает о себе знать, пользователи системы идут на различные хитрости: закрывают старую базу и открывают новую каждый квартал, пытаются удалить старые данные и т.п. Однако любой бухгалтер скажет Вам, что данные нужны ему не за квартал, а минимум за год и предпочтительно в динамике, а не в виде отдельных кусков. Да и долги клиентов иногда тянутся годами. Временным решением проблемы в такой ситуации может быть увеличение пропускной способности сети за счет установки 100-мегабитной сети вместо 10-мегабитной и интеллектуальных маршрутизаторов вместо тупых хабов. Однако, маршрутизаторы чрезвычайно дороги, а 100Мбит сеть даст повышение пропускной способности 2.5-3 раза (а не в 10 раз, как можно было бы ожидать!!!). Да и зачем увеличивать пропускную способность сети, если жесткий диск сервера уже работает на пределе своей производительности? Через пол-года Ваша база данных вырастет еще на 300-500Мб и система опять заткнется, пустив по ветру все вложенные в модернизацию денежки. Не следует забывать и еще об одной значительной детали. Это архивирование. Попробуйте заархивировать базу данных объемом 1-1.5Гб - за время потребное для архивации вы можете успеть пообедать, посмотреть кино и поругаться с начальником. А ведь это нужно делать каждый день. И при этом во время архивирования ни один из пользователей с базой работать не может.
Теперь рассмотрим SQL-систему ( т.е. клиент-серверную систему). Если кто-то говорит Вам, что у него сильно тормозит SQL - спросите его, какой у него сервер. Если он ответит, что-то вроде: "…Pentium 266, 64Мб ОЗУ и UDMA IDE", то можете смело сказать ему, что он … не слишком квалифицированный специалист. Серверы для SQL-систем должны иметь значительно большие ресурсы. PentiumII 300Mhz со 128Мб ОЗУ и Ultra Wide SCSI дисками - это пожалуй тот минимум, на котором может НОРМАЛЬНО функционировать программное обеспечение MS SQL Server с 5-8 подключенными клиентами. Заметьте при этом, что сеть с пропускной способностью 100Мбит совсем не обязательна. Все дело в том, что при работе с SQL-сервером рабочая станция не качает базу данных к себе по сети. Она просто передает по сети достаточно компактный запрос на сервер, который выполняет запрос, например производит выборку, и передает результат запроса обратно на рабочую станцию. Таким образом, трафик по сети значительно снижается, поскольку перекачки базы не происходит, а по сети передаются только запросы и результаты их выполнения. Конечно, если при разработке клиентской части программного обеспечения будет допущена ошибка и будет запрограммирован запрос, результатом выполнения которого является вся база данных или значительная ее часть, то вся эта информация будет качаться на рабочую станцию, выдавшую такой запрос. Но это уже по большей части лежит на совести разработчиков прикладных задач, т.е. применительно к программам "1С" - на совести тех, кто занимается настройками (и на совести разработчиков из "1С" - в части запрещения оптимизации таких запросов).
Теперь посмотрим, что же происходит с сервером в SQL-системе. Ведь север сам выполняет полученный запрос, поэтому, легко представить себе, что если с SQL-системой работают 10 пользователей, то для сервера это практически то же самое, как если бы на нем были одновременно запущены 10 экземпляров программы, с которой работают пользователи (например 10 локальных копий 1С-Торговли). Попробуйте запустить локально на каком-нибудь Pentium 200 или 266 десять экземпляров 1C-Торговли и выполнить одновременно 10 отчетов об остатках на складе. Сделав это и оценив результат Вы поймете, что всякие разговоры о "торможении" SQL-системы без обсуждения параметров сервера не имеют смысла. SQL-системы крайне прожорливы на ресурсы сервера. По-хорошему для таких систем вообще следует использовать компьютеры с RISC процессорами в многопроцессорном варианте (что-нибудь из продукции SUN Microsystems). Однако, для наших бедных клиентов с их ограниченными финансовыми возможностями SQL-системы все равно имеют существенное преимущество: даже при использовании сервера стоимостью 4-5 тыс. долларов они будут работать со вполне приемлемой скоростью с базами данных такого объема, на котором обычные файл-серверные системы просто заткнутся. Причем, этот объем может достигать величин в десятки ГИГАБАЙТ. Ведь доступ к данным очень быстр - они расположены здесь же, на диске сервера и не требуют передачи по сети для последующей обработки. Все запросы поступают к серверу, так что кроме обычного файлового кэширования есть огромные возможности по оптимизации выполнения запросов, их распараллеливанию. Эти возможности уже заложены в программное обеспечение MS SQL Server, а от разработчиков из "1С" требуется так написать исполняющую часть программы, чтобы использовать эти возможности в полной мере. Возможно также применение различных хитростей, например серверов-репликаторов (для разделения групп пользователей на тех, кто пользуется только отчетами, т.е работает в режиме "только чтение", и тех, кто активно модифицирует данные) или разноски данных по разным дисковым устройствам. При перегрузке дисковой системы она легко модернизируется, например с помощью RAID-массива (не забывайте однако, что SQL-система - это вообще иная ценовая категория как по цене матобеспечения, так и по цене железа). В результате при правильном проектировании системы (если не обнаружатся любители выдавать крутые запросы, результатом которых будет перекачка всей базы данных по сети), 100Мбит-ная сеть может не понадобиться. Вот что в первую очередь дает SQL-система. Вообще, SQL-система предоставляет значительные возможности для оптимизации аппаратной части и настройки программной части. И говорить о "торможении" SQL-системы имеет смысл только тогда, когда эти возможности исчерпаны.
До сих пор мы говорили о принципиальных различиях файл-серверных систем от клиент-серверных. Теперь немного о дополнительных преимуществах клиент-сервера.
Надежность. Клиент-серверные системы имеют встроенный механизм работы с транзакциями, в том числе и их отката. В файл-серверных версиях программ "1С" также имеется механизм работы с транзакциями, однако способ реализации их принципиально отличается. В файл-серверных версиях механизм транзакций представляет собой ни что иное, как просто блокировку всей базы данных до завершения выполнения критических по времени операций одной из рабочих станций. Откат возможен только при сохранении работоспособности рабочей станции, инициировавшей транзакцию. В клиент-серверной системе этот механизм (который реализуется программным обеспечением SQL-сервера - в нашем случае MS SQL Server 6.5) значительно более сложен. Он позволяет получить "слепок" базы данных на момент начала транзакции без блокировки базы данных. И слепков таких может быть много: для каждой рабочей станции - свой. В случае "зависания" рабочей станции, открывшей транзакцию, транзакция может быть просто откачена (т.е. база данных будет восстановлена в том виде, в каком она была до начала инициации транзакции). Откат осуществляется либо по запросу рабочей станции (при сохранении ее работоспособности), либо при перезагрузке рабочей станции, либо администратором SQL-системы. Таким образом, выход из строя рабочей станции не столь опасен для целостности базы данных. Кроме того, SQL-система ведет так называемый журнал транзакций. По сути база данных хранится в виде ее начального содержимого и ее модификаций записанных в журнал транзакций. Такой способ хранения позволяет производить архивирование базы данных во время работы всей системы: просто состояние базы данных фиксируется на момент начала архивирования, отсекаются незавершенные транзакции, а основная база и часть журнала транзакций, содержащая завершенные транзакции записываются в архив. Процесс архивирования легко поддается автоматизации, т.е. присутствие оператора необязательно - SQL-сервер имеет встроенные средства для этого.
Защита. В общем-то защищенность данных в значительной мере зависит от прикладной задачи (1С-Торговли или 1С-Расчета), однако по сравнению с обычным вариантом, в котором любой начинающий хакер спокойно может срубить пароль, в клиент-серверном варианте защита данных опирается на средства, предоставляемые SQL-сервером, что гораздо более недежно.
Гибкость применения. Системы на основе SQL-сервера позволяют построить сложные сетевые конфигурации со многими десятками и даже сотнями пользователей. При этом разработчику предоставляются широкие возможности по оптимизации системы, ее разделению по группам сложности и способам доступа. Серверы-репликаторы, например, дают прекрасный механизм для организации системы учета в крупной организации с разветвленной системой удаленных офисов, складов и т.п. При этом, работа на такой системе может вестись в реальном режиме времени, без перерывов для переноса и синхронизации данных - достаточно лишь организовать постоянные каналы связи 32-128 Кбит, что вполне осуществимо на наших телефонных линиях и не слишком дорого (конечно, в масштабе крупной компании).
Ну и наконец пора поговорить о недостатках. Недостатков у SQL-систем много - и крупных и мелких - тех же самых, которые присущи и файл-серверным системам. Однако есть два и весьма существенных.
Первый Вы наглядно увидите в прайсе фирмы "1С" - это цена. Цена не только программного обеспечения, но и цена железа на котором оно может функционировать и цена обслуживания. Ну, что же делать - SQL это продукт высоких технологий. А продукт высоких технологий всегда стоит дорого и должен эксплуатироваться грамотным персоналом, поэтому и системный администратор, способный грамотно работать с SQL-системой обойдется дороже, чем аналогичный специалист для обычной файл-серверной системы.
Второй - это существенные недоработки клиентской части программ комплекса 1C:Предприятие для SQL. В тех версиях, которые пока выпущены в продажу, далеко не полностью используются преимущества SQL сервера. Разработчик или поленился или не успел реализовать в полной мере возможности, предоставляемые средствами SQL сервера, поэтому во многих случаях там, где можно ожидать выполнения несложного SQL-запроса программа просто (как это делалось и в файл-серверной версии) перекачивает на локальный компьютер всю базу данных, вернее ее часть, и затем продолжает работу с локальной копией. Это с "внутренней" точки зрения, а внешне, для пользователя это выливается в те самые "тормоза" о которых пишут в конференции. Остается только надеяться, что со временем фирма "1С" доработает свои SQL-продукты таким образом, что функциональность SQL-сервера будет использоваться значительно более полно. В оправдание фирмы "1С" могу заметить, что программный продукт такой сложности всегда развивается постепенно - ведь если пытаться выпустить на рынок полностью "вылизанный" продукт высочайшего качества, то этого можно просто не дождаться. Все софтверные компании, выпускающие продукты высокой степени сложности идут именно по пути постепенного улучшения первоначально выпущенного продукта. Тот, кто пытается нарушить эту традицию обычно терпит крах на этом пути. Достаточно вспомнить историю с выпуском Windows 95 фирмой Microsoft: выпуск продукта все оттягивался и оттягивался, несмотря на многократные анонсы и переносы сроков, и в конце концов на рынок был выброшен недоработанный продукт. А уже потом были выпущены OSR1 и OSR2, однако продукт так и стался "сырым".
Теперь пора подвести некоторые итого. Не ждите, что SQL-системы будут работать быстро. Но они смогут работать там, где файл-серверный вариант не сможет, или же будет создавать существенные неудобства (удаленный доступ). Однако и обойдется это Вам не дешево.
Вот, пожалуй, и все. Надеюсь, что этот краткий обзор позволит Вам хоть немного сориентироваться в вопросе, что такое SQL и зачем он нужен.
Почему возникает потребность в привязке программ 1С.
В бухгалтерском учете выделяется группа учетных задач, которые имеют "прозрачную" содержательную сущность и строго регламентированные алгоритмы решения. Такие задачи базируются на нормативных документах по организации бухгалтерского учета, мало зависят от вида деятельности предприятия и особенности хозяйственной деятельности. Программы 1С в значительной степени автоматизируют именно эти задачи, что позволяет им стать универсальными и применяться с незначительной адаптацией. В то же время в учете имеется множество задач, отражающих специфику видов деятельности, предполагающих многовариантность организации и методов ведения учета. Задач такого рода в программах 1С значительно меньше, чем унифицированных, высока вероятность, что их надо дорабатывать при привязке к предприятию (организации).
Программа 1С рассматривается как система, для которой установлены назначение, область применения, условия и правила использования без изменений или с незначительной доработкой к конкретным условиям.
Подключение
Подключение компоненты «Управление распределенными информационными базами» выполняется автоматически в момент запуска системы 1С:Предприятие. Признаком успешного подключения компоненты является доступность режима «Управление распределенными данными». Этот режим можно вызвать, выбрав пункт «Распределенная ИБ - Управление» из меню «Администрирование» главного меню Конфигуратора.
This site is hosted for FREE on VirtualAve -- yours can be, too! Click here for more information.
Подписание акта сдачи-приемки
Подписание акта приемки-сдачи работ - очень важный этап, который недооценивается многими сотрудниками.
Необходимо довести до сознания сотрудников, что работа закончена тогда и только тогда, когда деньги пришли на расчетный счет или в кассу и подписаны все документы со стороны заказчика (в частности - акт приемки-сдачи работ). Если не подписан акт, то заказчик вправе предъявлять претензии по уже закрытым (с точи зрения сотрудника!) работам, и бывает очень тяжело объясни заказчику, что это уже другие работы, за которые надо платить новому.
Поиск и замена данных
Поиск и замена данных
В режиме Таблицы предусмотрены возможности поиска данных по образцу либо в конкретном поле, либо во всей таблице.
Чтобы найти необходимые данные, нужно:
-
Открыть таблицу в режиме Таблицы.
Если известно, в каком столбце нужно вести поиск, выделить этот столбец (достаточно поместить курсор в любое поле этого столбца).
Нажать кнопку Найти (Find) на панели инструментов Режим таблицы (Table Datasheet) и открыть вкладку Поиск (Find) или выполнить команду меню Правка, Найти (Edit, Find). Появится диалоговое окно Поиск и замена (Find and Replace) (рис. 2.54).
Пояснение
ИБ
Информационная база
Центральная ИБ
Привилегированная ИБ, исполняющая роль центра в рамках информационной системы всего предприятия. Как правило, территориально расположена в центральном офисе
Периферийная ИБ
ИБ территориально удаленного подразделения предприятия
«Ведущий» объект
Элемент данных системы - константа, элемент справочника, конкретный документ. Сама конфигурация также является «ведущим» объектом для центральной И Б
Файл переноса данных
Файл, содержащий совокупность измененных, добавленных и удаленных «ведущих» объектов
Файл первичной выгрузки
Файл переноса данных, формируемый центральной ИБ при создании образа новой периферийной ИБ
Построение технической архитектуры
Практические проблемы внедрения
Практика внедрения системы "1С: Предприятие" демонстрирует наличие ряда серьезных проблем, связанных, среди прочего, с недостаточностью методической проработки процесса внедрения. Некоторые примеры приведены ниже.
|
Реинжиииринг бизнес-процессов. Разработка архитектуры прикладной системы |
Отсутствие методик и инструментальных средств Нехватка квалифицированных системных и бизнес аналитиков Неготовность клиента |
|
Переход к новым версиям при комплексной поставке |
Организационные, технологические и психологические проблемы, связанные с переходом к новому уровню автоматизации. |
|
Стратегия реализации и конфигурирование |
Организация и управление проектом. |
|
Ввод в эксплуатацию |
Организация и технология перехода на новую систему в масштабах предприятия. |
|
Перенос данных |
Разноформатность данных. Перенос с бумажных носителей. |
|
Обучение |
Отсутствие проработанных методик. Разный уровень подготовки клиентов. |
|
Интеграция с другими системами |
Различия в архитектуре и средствах реализации. Закрытость внешних систем. Нехватка инструментальных и методик средств интеграции. |
Преобразование данных
Лист учета рабочего
Лист учета рабочего времени
Организация
Сотрудник
|
Дата |
Начало работы |
Конец работы |
Кол-во часов |
Содержание работы |
Подпись исполнителя |
Подпись заказчика |
Пакетный режим автообмена УРБД
Наличие в системе "1С:Предприятие 7.7." пакетного режима запуска значительно облегчает осуществление автообмена ИБ. При этом исключается потребность лезть руками в "Конфигуратор" и снижается вероятность ошибки со стороны неопытных пользователей. Автообмен сводится к простому "клику" по ярлыку, например такого содержания:
"C:\Program Files\1Cv77\BIN\1cv7.exe" CONFIG /DF:\База /NПупкин /Pмойпароль /@F:\База\paket.prm
| Параметр | Значение | Описание | |||
| config | Запуск 1С:Предприятие в режиме конфигуратора | ||||
| /D | F:\База | Путь к каталогу ИБ | |||
| /N | Пупкин | Имя зарегистрированного пользователя | |||
| /P | мойпароль | Пароль пользователя Пупкин. Если пароля нет, то параметр можно не указывать. | |||
| /@ | F:\База\paket.prm | Путь к файлу параметров пакетного режима запуска. Представляет собой текстовый файл по типу *.INI-файлов Windows |
Пример содержания файла параметров пакетного режима:
[General] ;Общий раздел
AutoExchange=1 ;Выполнение раздела "AutoExchange (Автообмен)" (1-да, 0 -нет)
Quit=1 ;Выйти из Конфигуратора по завершении (1-да, 0 -нет)
[AutoExchange] ; Раздел"Автообмен"
SharedMode=1 ; Раздельный (1)/Монопольный (0) режим
WriteTo=РТ* ; Коды баз выгрузки (шаблон или через запятую)
ReadFrom=РТ* ; Коды баз загрузки (шаблон или через запятую)
ы:
Примеры:
ddd", "d\ imranm\ yyyy Пн, 1 января 2001
dd\ mmm\ уу 01 ЯНВ 01
dddd", "dd\ mmmmm\ yyyy понедельник, 01 января 2001
Замечание
Специальные форматы выводятся в соответствии со значениями, установленными в окне Язык и стандарты панели управления Windows. Специальные форматы, противоречащие настройкам окна Язык и стандарты, игнорируются.
Замечание
В Access различаются понятия пустого значения и строки нулевой длины. Если поле имеет значение Null — пустое, то это означает, что поле не имеет никакого значения. Если значением текстового или МЕМО-поля является строка нулевой длины, то значение этого поля известно — пустая строка. Пустое значение не может быть равно никакому значению, в том числе другому пустому значению, поэтому связывать таблицы по значению Null нельзя. Пустые строки считаются равными друг другу, поэтому по пустым строкам таблицы связывать можно.
Принципы разрешения спорных ситуаций
При работе распределенной системы с периодическим обменом данными могут возникать спорные ситуации (коллизии). Ниже дан перечень коллизий и алгоритмы их разрешения системой. Эту информацию следует иметь в виду при создании новой конфигурации и при проведении организационных мероприятий по внедрению распределенной ИБ на базе системы 1С:Предприятие.
Только после того, как все ИБ системы, которые поддерживают синхронизацию «ведущего» объекта, подтвердили его прием, информация о его изменении удаляется системой, и процедура корректировки распределенной ИБ заканчивается. Если же в течение этого промежутка времени другая ИБ внесла в объект свои изменения, то такие корректировки можно считать условно одновременными. Коллизии могут возникать при условно одновременном изменении «ведущего» объекта двумя или более ИБ единой распределенной информационной базы.
|
Коллизия |
Алгоритм |
|
Один и тот же объект изменен более чем в одной ИБ |
Если одна из ИБ - центральная, то определяющими считаются изменения, сделанные в ней. В периферийных ИБ состояние объекта при следующей выгрузке-загрузке будет приведено в соответствие с центральной. В противном случае определяющими считаются изменения, дошедшие первыми до центральной ИБ. |
|
Объект, удаленный в одной из ИБ, не может быть удален в другой, так как в другой ИБ на пего имеются ссылки |
По окончании процедуры корректировки распределенной ИБ объект будет восстановлен всеми ИБ, поддерживающими его синхронизацию. |
|
Объект, измененный в одной ИБ, был удален в Другой |
Определяющим действием считается изменение. По окончании процедуры корректировки распределенной ИБ объект в измененном виде будет восстановлен всеми ИБ, поддерживающими его синхронизацию. |
Значение на определенную дату периодического реквизита справочника или счета, а также значение периодической константы не является «ведущим» объектом: ими могут быть только константа, элемент справочника, счет, вместе со всей историей изменения периодических реквизитов. Поэтому, при условно одновременном изменении периодической константы, элемента справочника, счета, по окончании процесса корректировки распределенной ИБ принятым окажется только одно изменение, даже если корректировка периодического значения производилась для разных дат.
Принятие решения о составе системы и подготовка коммерческого предложения
От выбора состава всего комплекса (как программной, так и аппаратной составляющих) зависит качество и скорость выполняемых у клиента работ. Поэтому очень важно до начала работ у клиента определиться, на каком ПО и с каким оборудованием мы будем работать.
Будем разделять программное обеспечение «1С» и программное обеспечение сторонних производителей (Microsoft, Novell и т.д.). Фактически необходимо рассматривать структуру, приведенную на рисунке:
Принятые обозначения
Для лучшего понимания излагаемого материала в настоящем Описании приняты некоторые общие приемы выделения отдельных элементов текста. Соглашение о таких приемах приведено ниже.
Обозначения кнопок. Наименования кнопок в диалогах будут даваться их названиями в кавычках, например, «ОК», «Закрыть» и т.д.
Процессы и задачи выполнения проекта
| 1.2 | 01-БП |
Процессы управления проектом
| nn-УО | Контроль и отчетность | |||
Программное обеспечение
При выборе программного обеспечения для построения информационной системы у клиента, необходимо определиться с двумя основными моментами: какая платформа фирмы «1С» будет использоваться, и какая конфигурация будет работать на этой платформе. Фактически выбор серверной части системы зависит от сложности конфигурации и количества рабочих мест в сети.
При определении, какая платформа фирмы «1С» будет использоваться в нашей системе, следует принимать во внимание следующие замечания:
если количество рабочих мест, работающих одновременно, более 7-10 - должна использоваться SQL-серверная версия платформы (следовательно, сетевая ОС - Windows NT Server);
если планируемых размер базы данных более 400-500 МБайт - должна использоваться SQL-серверная версия платформы (следовательно, сетевая ОС - Windows NT Server);
если важна надежность базы данных (причем минимальный размер базы не играет роли), то следует использовать SQL-серверная версию платформы как более надежное решение;
если не планируется использование выделенного сервера, то не рекомендуется использовать более 3 рабочих станций, при этом в качестве операционной системе на «сервере» следует использовать Windows NT Workstation.
(Данная рекомендация обусловлена тем, что ОС Windows 9х имеет ограничение в 1024 открытых «через сеть» файла. ОС Windows NT Workstation не имеет таких ограничений.)
во всех остальных случаях следует использовать файл-серверную версию платформы
если планируется использовать файл-серверную версию платформы, то рекомендуется ставить операционную систему Novell NetWare.
Таким образом мы видим, что ключевое влияние на состав всей информационной системы оказывает выбор варианта системы программ «1С:Предприятие». Следовательно, необходимо начинать комплектацию информационной системы именно с выбора варианта системы «1С:Предприятие».
Обязательно надо следовать следующему правилу - сетевое программное обеспечение должен устанавливать специалист (желательно сертифицированный соответствующей фирмой). Соблюдение этого правила дает гарантию устойчивой работы всего программно-аппаратного комплекса.
Следующий шаг, который нужно рассмотреть при комплектовании информационной системы клиента – конфигурация, которая будет обслуживать бизнес-процессы клиента. Можно выбирать из трех различных вариантов конфигураций: типовые (идут вместе с коробкой), отраслевые конфигурации третьих фирм и заказные решения.
Психология клиента и как с ней бороться
© Copyright Alter Vita Ltd., 2000. All Rights Reserved. Все пpава в отношении данного текста пpинадлежат компании Альтер Вита. Пpи воспpоизведении текста или его части сохpанение Copyright обязательно. Коммеpческое пользование допускается только с письменного разрешения компании Альтер Вита.
Как всякое авторское творение, данное выступление не лишено значительной доли субъективизма, хотя основано оно на опыте реального общения с клиентами-заказчиками нашей компании и не содержит ни малейшей примеси фантазии.
Начнем, пожалуй, с сервисного обслуживания, или иначе «сопровождения». Основными задачами таких услуг является поддержание в работоспособном состоянии компьютерной техники, локальной компьютерной сети и программного обеспечения предприятия-клиента, небольшая доработка прикладного программного обеспечения, установленного на предприятии и консультации/обучение персонала клиента.
Вот типичная ситуация. Клиент – небольшая компания, имеющая в своем распоряжении 4-5 компьютеров, включенных в локальную сеть, выделенного сервера нет (его роль выполняет один из компьютеров) и пару принтеров. На компьютерах установлена сетевая версия складской/бухгалтерской программы. Поскольку клиент торгует со склада не только оптом, но и в розницу, с программой идет довольно интенсивная работа. Завершаем работу по установке и настройке программного обеспечения, запускаем в работу всю систему, немножко обучаем персонал. Поскольку до нашего участия компания уже использовала локальные версии тех же программ, особых усилий на обучение не требуется. На этом наше участие во внедрении заканчивается. Завершаем расчеты с клиентом и интересуемся, не хочет ли он заключить с нами договор на абонементное обслуживание своей системы. Мы знаем, что такое обслуживание, может быть и в небольшом объеме, но обязательно нужно, поскольку своего специалиста ни по железу, ни по программному обеспечению у клиента нет, а квалификация персонала во всем, что непосредственно не связано с бухгалтерией, далеко не самого высокого уровня (во всяком случае, подключение отвалившегося сетевого принтера выливается в неразрешимую проблему даже при подробных инструкциях по телефону). Наше предложение с финансовой точки зрения, как нам кажется, весьма привлекательно и сводится примерно к следующему: ежемесячно клиент платит нам 100 долларов и имеет право за эти деньги вызвать нашего специалиста к себе на объект до 5 раз в месяц. Специалист обязан прибыть к клиенту не позднее трех часов после вызова. Общее время работы специалиста у клиента не должно превышать 10 часов (то есть, 5 вызовов по два часа или в любых других комбинациях). Это в ДВА С ПОЛОВИНОЙ РАЗА дешевле, чем просто почасовая работа нашего специалиста (часовая ставка 25 долларов). Единственное, что мы хотим взамен – это выплату ста долларов абонементной платы ежемесячно, вне зависимости от того, понадобилась ли наша помощь клиенту в текущем месяце или не понадобилась. Кстати, если клиенту потребуется дополнительные часы работы наших специалистов, сверх предусмотренных договором лимитов, то мы не бросим клиента, а сделаем все от нас зависящее, чтобы его система работала, и при этом возьмем дополнительную оплату по льготному почасовому тарифу (15 долларов в час вместо 25) – это тоже предусматривается договором. На наш взгляд, условия договора со всех сторон выгодные для клиента и совершенно невыгодные нашей компании (вернее нам они тоже выгодны, когда количество клиентов, обслуживаемых по подобным договорам, переваливает за десяток).
Как же реагирует на такое предложение клиент? Сначала тот, кто ведет переговоры со стороны клиента (директор или чаще главный бухгалтер) с удивлением вопрошают: «А что, это все еще и обслуживать надо?!». Работают они с вычислительной техникой не первый день и прекрасно знают, что «…это все еще и обслуживать…» обязательно надо. Просто сделав вид, что это им неизвестно, они получают возможность при первой же неисправности или просто при ошибке пользователя, позвонить нам и дико возопить, что «…вот вы тут у нас что-то сделали, а теперь все не работает…». И это не из-за незнания, а из острого желания получить обслуживание своей системы, к которой мы имели несчастье приложить руки, навечно и бесплатно. Ну с этим вопросом обычно удается разобраться быстро, дав клиенту понять, что бесплатно он больше от нас ничего не получит, кроме кратких телефонных консультаций и гарантийного ремонта компьютеров и сетевого оборудования (что и было предусмотрено договором). А дальше опять плавно переходим к абонементному договору, объясняя, что это именно то, что им надо, причем достаточно дешево. Вот тут то и начинается! Два ключевых вопроса. Первый: «…а за что это мы должны Вам платить, если у нас за месяц ничего не сломается и мы Вас вызывать не будем?» и второй: «…а откуда мы знаем, что вы не будете просто сидеть тут у нас и делать вид, что работаете, просто накручивая на счетчик?». Начинаем дискуссию по первому вопросу, объясняем, что деньги берем за то, что мы всегда «на низком старте», готовые гарантировано быстро к ним приехать в случае каких либо неприятностей, в то время как обычные вызовы обслуживаются нами по возможности, как правило, в течение двух-трех суток с момента вызова. Объясняем, что для работы с абонементными клиентами нам нужно содержать кроме технических специалистов еще и склад запчастей и диспетчерскую службу. Да и технических специалистов надо больше, чтобы всегда был хотя бы один свободный для осуществления экстренного вызова. Пускаемся в пространные объяснения самого понятия «абонементное обслуживание», проводим аналоги с бытовой техникой, автосервисом и т.п. В ответ обычно заявляют, что им проще нанять себе сотрудника… Начинаются расчеты затрат на сотрудника и расходов на оплату абонементного договора и сравнение плюсов и минусов того и другого варианта. В итоге наемный сотрудник (равноценный по широте квалификации и к тому же никогда не болеющий и не ходящий в отпуск) проигрывает и по затратам и по плюсам и минусам. Теперь переходим ко второму вопросу. Это самое сложное. Кроме рекомендаций других наших клиентов и голословных заявлений о том, что нам самим не выгодно, чтобы наш человек сидел у клиента и «наматывал» часы, мы никаких аргументов привести больше не можем. Но, в конце концов, клиент великодушно снисходит к тому, чтобы нам поверить. Дальше обсуждаем разные детали. Переговоры прерываются, клиент просит тайм аут, чтобы подумать.
Через пару дней клиент звонит и радостно сообщает, что они готовы заключить договор, все условия их удовлетворяют, только пусть при тех же условиях цена будет не 100 а 60, а лучше 50 долларов – большего они не могут себе позволить. Все. Клиент потерян. Дальнейшие переговоры бессмысленны. Налицо явная попытка получить бесплатный пряник. И это при том, что фирма-клиент, хоть и небольшая, однако, ее месячный оборот переваливает за несколько сот тысяч долларов и при остановке или сбое компьютерной системы убытки могут исчисляться десятками тысяч долларов. И при всем при этом острое желание сэкономить 50 долларов в месяц. Просто абсурд.
Самое забавное в этой ситуации, что весьма вероятно, что работать с этим клиентом мы все-таки будем. Только клиенту это обойдется дороже в финансовом смысле, а нам в смысле моральном. Через пару месяцев у нас в офисе раздастся телефонный звонок и разъяренный главный бухгалтер этой самой фирмы надрывно начнет ту же песню о том, что «…вот вы нам тут плохо сеть сделали и у нас ничего теперь не работает…» и «…чтобы срочно приезжали все исправляли, а то…» (дальше следует список ожидающих нас неприятностей). И это после двух месяцев нормальной работы всего, «что мы там сделали». Наши разговоры о том, что любая компьютерная система требует регулярного обслуживания напрочь забыты: свои грехи нужно спихнуть на кого-то. Начинаем разбираться (пока по телефону). Сначала спрашиваем, а работало ли «все, что мы там сделали» до сегодняшнего дня. Клиент быстро соображает, что допустил ошибку и заявляет, что, конечно же, ничего не работало, но им не особо и нужно было, поэтому они и не звонили. Начинаем крутить этот вопрос и так и этак, и если все-таки здравый смысл возобладал, то разговор переходит в нормальное русло, т.е. договариваемся с клиентом, о том, чем мы сможем ему помочь и сколько это ему будет стоить (в большинстве случаев требуется просто восстановить разрушенные неграмотными пользователями настройки сетевых протоколов и т.п.). Если же клиент невразумляем и твердо задумал вывернуть нас наизнанку, то ему задается простой вопрос: «А у Вас на компьютерах Windows лицензионный?». Windows у них нелицензионный, но суть не в этом. Поняв, что дальше мы с ними объясняться не собираемся, клиент либо просто начинает угрожать (варианты разные: бандиты, арбитражный суд, жалоба в налоговую инспекцию и т.п.), либо поняв, что наездами от нас ничего не добиться, все же переходит к конструктивным переговорам. Вариант с угрозами здесь рассматривать не будем – эти проблемы каждый решает по-своему. Ну а в случае достижения консенсуса, мы договариваемся о выезде к клиенту наших специалистов (разумеется, за нормальную почасовую оплату) и действительно стараемся прислать к нему людей побыстрее, чтобы он понял преимущества абонемента. Самое обидное для клиента (хотя он этого и не знает), это то, что если бы он позвонил нам и не скандалил, не качал права (а качать права нет даже формального повода – гарантийный срок дается только на компьютеры и сетевое оборудование, а с ним все в порядке), а просто попросил помощи, то мы бы обязательно ему помогли, и, вероятно, даже дали бы скидку. Когда проблема решена, можно опять вернуться к вопросу об абонементном договоре. Иногда это срабатывает с первого раза, иногда со второго или третьего. Иногда вообще не срабатывает, особенно когда на данном предприятии подвизается какой-нибудь отрок с косичкой и немытыми волосами, изображающий из себя асса компьютерного дела. В послекризисные времена с такими личностями приходится сталкиваться достаточно часто, поэтому следует посвятить несколько строк их общему описанию, чтобы в случае необходимости Вы легко смогли опознать такой экземпляр. Высшего и даже среднего технического образования они, как правило, не имеют. Зато часами сидят в Интернете и участвуют во многочисленных конференциях, засоряя их полнейшей чепухой. Их лексикон изобилует массой специальных терминов, почерпнутых их околокомпьютерной литературы и интернетовских чатов. На их личных компьютерах установлены все существующие операционные системы. И конечно они преисполнены собственного величия. Однако, если поинтересоваться у такого существа, что такое алгоритм Лемпеля-Зива-Уэлча, то последует немая сцена из «Ревизора» Гоголя. Они с одинаковым успехом могут пытаться сжать архиватором файл, расположенный на диске, обработанном Drive Space-ом и отбраковать видеоадаптер с 2Мб видеопамятью только потому, что он не желает работать с разрешением 1024х768 и 32 разрядным цветом. Но… у них у всех есть одно существенное преимущество: их можно нанять за 50 баксов в месяц. Правда, почему-то никому из руководства предприятия не приходит в голову обратить внимание на то, что за свои 50 баксов такой субьект будет появляться на работе не более одного раза в неделю, да и то - на пол дня. А когда случится аварийная ситуация, искать его будут всей конторой и найдут только через пару дней. Да и техника и программное обеспечение, которые он обслуживает почему-то станут доставлять персоналу предприятия массу неприятностей. Но, несмотря на все это, магическая сумма в 50 долларов делает свое черное дело. Конечно, после крупного прокола с серьезными финансовыми потерями (а такой прокол рано или поздно обязательно случится) сего отрока погонят взашей, но его место займет такой же точно субъект. И только после того, как и этот т.н. «сисадмин» будет с позором изгнан, клиент может обратить свои взоры в нашу сторону. Но и в этом случае клиента ожидают дополнительные финансове потери. Мы ни в коем случае не возьмем на обслуживание предприятие в том виде, в котором его оставили эти горе-специалисты. Сначала нужно обследовать технику и софт, потом наладить то, что они разрушили. Все это стоит клиенту денег, а он их платить очень не хочет. Но и мы не можем взять на себя обязательства (довольно жесткие) по обслуживанию предприятия, если оно останется в том же виде, до которого его довели. Снова складывается ситуация, которую мы уже проходили. И начинается второй круг.
Так в чем же причина? Почему руководители предприятий, которым совершенно очевидно требуется партнер, который возьмет на себя заботы об их технике и программном обеспечении не в состоянии принять правильное решение? Ведь ситуация может быть просто экономически просчитана.
Оставим в стороне предприятия, которым действительно требуется постоянно присутствующий свой сотрудник. Обычно это предприятия с большим количеством (больше 20) разномастных рабочих станций, несколькими серверами, изобилующее принтерами и… с крайне неквалифицированным (в смысле обращения с вычислительной техникой) персоналом. Внедрив на таком предприятии систему мы сами обычно рекомендуем им нанять себе сотрудника, поскольку взяв такое предприятие на абонементное обслуживание мы просто будем вынуждены отрядить кого-то из своих специалистов для постоянного пребывания у этого клиента (а он естественно за такое количество часов работы платить не желает). Мы не только рекомендуем нанять сотрудника, но и сообщаем руководству предприятия-клиента те квалификационные требования, которым должен отвечать данный сотрудник и примерную величину оклада, соответствующую этим квалификационным требованиям. Ведь мы лучше, чем клиент знаем рынок труда в этой области. Несмотря на это в большинстве случаев все развивается по описанному выше сценарию: нанимается копеечный «крутой» специалист, который за несколько месяцев приводит компьютерную систему предприятия в неработоспособное состояние… а затем следуют телефонные звонки нам.
Так в чем же причина? Почему предприятие, оборот которого составляет несколько сотен тысяч (а зачастую и несколько миллионов) долларов в месяц не может нанять себе специалиста с окладом 400-600 долларов или заключить с нами договор на обслуживание на 100-300 долларов в месяц? Почему максимальная сумма, которую предприятие готово потратить на это не превышает 50 долларов? Дело в руководителе. Причем, практически в 100 процентах случаев речь идет о руководителе самого высшего звена: генеральном директоре, исполнительном директоре и т.п. Решение тратить или не тратить и, если тратить, то, сколько тратить, принимает не тот, кто работает с системой. Обычно, непосредственно за работу компьютерной системы отвечает главный бухгалтер предприятия. Он же пользуется теми благами, которые использование этой системы дает предприятию. И, как правило, главный бухгалтер, понимает, что нужно, чтобы эту систему эксплуатировать. Другими словами, имей мы дело только с главным бухгалтером, все было бы прекрасно: предприятие было бы у нас на абонементном обслуживании или там работал бы свой грамотный специалист. Увы, решения принимает другой человек. И вот здесь самое любопытное. Из опыта общения с такими прижимистыми руководителями я вынес твердое убеждение: они четко делятся на две категории. Первая – это та, где руководитель прекрасно понимает, что то, что ему предлагают, это нужно его предприятию, понимает, что это экономически оправдано, но… он не может и не хочет так вот сразу сдаваться. Он будет торговаться. Причем торговаться он будет до тех пор, пока он не сможет сказать себе: «Да, я молодец. Вот как я опустил этих ребят – почти задаром работать будут». Не понимая экономических оснований наших, с его точки зрения невыгодных нам, но выгодных ему, предложений, он решает, что его предприятие почему-то так нам нужно, что мы прямо из кожи вон лезем, чтобы взять его на абонементное обслуживание. А раз так, значит можно торговаться и сбивать цену в два, три и т.д. раза. На мой взгляд, такое поведение можно объяснить только одним: очень большой процент руководителей (а они же обычно являются и владельцами) мелких и средних предприятий выросли на обычной толкучке, на челночном бизнесе и т.п. Образование и некоторый опыт работы в доперестроечный период позволяют таким руководителям понять необходимость обслуживания компьютерной системы их предприятия, но рыночные привычки все равно берут верх. Страсть к сбиванию цены у них уже в крови и торгуются они до посинения. Вторая категория руководителей – это люди, которые считают, что все всегда их обманывают или пытаются обмануть. Обычно это бывшие партийные, профсоюзные и прочие функционеры. Высшего образования они не имеют. За плечами у них длительная практика интриг и подсиживания, но абсолютно никакого понимания, что такое компьютеры и зачем они вообще нужны (кроме компьютерных игр). Компьютерная система у них на предприятии внедряется только потому, что сейчас все так делают (да и главбух давно просит…). На рабочем столе у таких руководителей обязательно есть компьютер (престиж!), но где расположена кнопка включения знает далеко не каждый из них. Их психология проста как грабли. Пятьдесят долларов – это та сумма на которую они могут позволить обмануть себя. Но ни центом больше. Они готовы будут заплатить больше только в том случае, если после длительных поисков не найдут никого, кто бы согласился на эту цену (качество услуг в расчет не принимается – оценить его они просто не могут).
Вообще, разговоры с руководством предприятия-клиента – это тема для большой статьи или даже отдельной книги. Иногда я просто не могу понять, действительно ли директор, с которым ведутся переговоры глуп, или он просто искусно притворяется идиотом. Возьмем простой пример. Кажется, всем давно известно, что гарантия на изделие означает только то, что в период гарантийного срока это изделие поставщик обязан бесплатно отремонтировать или заменить в случае выхода его из строя. И действительно, все это понимают, пока дело касается автомобиля, холодильника, музыкального центра и т.п. Но, как только речь заходит о компьютерах, эти знания сразу улетучиваются из головы клиентов. Почему-то они пребывают в твердой уверенности, что «гарантийные обязательства» на поставляемую технику, смонтированную сеть и т.п. означают, что эти изделия не могут, ну просто не имеют права, сломаться в период действия гарантийного срока! Вы не представляете, каких усилий стоит убедить клиента (руководителя), что это не так. Но даже, если его все-таки удалось убедить – это еще не победа. Не дай Бог, что-то действительно выйдет из строя. Претензии будут выставляться не на тему бесплатного ремонта, а на тему покрытия убытков, вызванных поломкой оборудования, даже в случае, если убытков фактически не было. В такой ситуации спасательной палочкой является договор на поставку оборудования с прописанными в нем обязательствами поставщика (гарантийный ремонт, гарантийный срок) и четкой росписью, за что и в каком случае поставщик несет материальную ответственность.
Наглядным примером вышесказанному может послужить тот факт, что из всех клиентов нашей фирмы, только один имеет в горячем резерве сервер. Да и то этот резервный сервер был установлен только после того, как старый единственный сервер «упал» и его восстановление заняло целый рабочий день, что вылилось в несколько тысяч долларов убытка для клиента. Этот клиент был у нас на абонементном обслуживании, и нас спасло только то, что в дирекции предприятия-клиента имелась наша, соответствующим образом зарегистрированная, докладная записка с описанием возможности подобной аварийной ситуации и рекомендацией немедленной установки резервного сервера.
Теперь о программном обеспечении, в частности о ПО 1С:Предприятие. Здесь также имеются свои особенности. Чаще всего неприятности возникают не со специально написанными под клиента «настройками», а с типовыми конфигурациями, которые устанавливаются клиенту без внесения каких бы то ни было изменений. В случае написания индивидуальной настройки все обстоит достаточно просто: у нас есть индульгенция под названием «Акт о приемке работ». Если клиент подписал «Акт» - значит его все устраивает (конечно, если в договоре на разработку не оговорено иное). Все выявленные в последующей эксплуатации ошибки и недоработки исправляются нами либо бесплатно (если это действительно наша ошибка), либо за соответствующую оплату. Но в любом случае формально мы не обязаны это делать. В случае же типовых конфигураций, обычно конфликт возникает на почве того, что клиент не находит в конфигурации того, что ожидал там найти. Может быть, этого действительно там нет, хотя чаще случается, так, что клиент, просто не прочитав ужасно толстые книжки с описанием конфигурации, с помощью наезда на нас пытается получить бесплатное обучение или мелкие доработки. В такой ситуации от нас требуется особое упорство. Поскольку лицензионного соглашения на покупку ПО фирмы «1С» в прилагаемых к коробочкам документах не существует, то нам остается только твердо стоять на том, что «…программа полностью соответствует прилагаемой документации…». Хорошо если это действительно так. В противном случае приходится бесплатно исправлять ошибки в типовых конфигурациях или возвращать клиенту деньги и забирать коробочку. Такое случается не часто, но все же случается. Обычно, подобная ситуация возникает, когда будущие пользователи ПО 1С:Предприятие почему-то решили, что купив данный продукт, они избавят себя от необходимости вводить накладные и формировать счета, вбивать данные о сотрудниках и делать сложные проводки. Они мечтают о том, что квартальный баланс будет формироваться сам по себе одним щелчком мыши. Ясно, что такие представления об использовании бухгалтерского ПО произрастают на почве компьютерной безграмотности значительной части потенциальных пользователей и руководства предприятий. И, кроме того, они обильно подпитываются различными рекламными публикациями. Что ж, это, конечно, все преодолимо, но… стоит значительных усилий, нервов и денег.
Существует категория руководителей с которыми практически невозможно вести какие бы то ни было дела. Это – бывшие программисты. Они давно ушили в бизнес, превратились в администраторов (часто очень неплохих администраторов). Иногда они находят время почитать различные журнальчики по компьютерной тематике. Иногда они даже пытаются что-то запрограммировать на Access. И они считают, что уж в чем, в чем, а в компьютерах и в программном обеспечении они разбираются гораздо лучше, чем наши специалисты. Встретив такого руководителя Вы можете твердо быть уверены - работать они Вам не дадут. И денег не заплатят. Есть только один метод, который можно попробовать для борьбы с ними. Вероятность успеха – пятьдесят на пятьдесят. Нужно просто разговорить такого руководителя на техническую компьютерную тему и крепко посадить его в лужу. Если руководитель нормальный, здравомыслящий человек, то скорее всего он поймет все правильно и дальше уже все будет зависеть от Вашей работы. Если же Вы нарветесь на самодура – прощай клиент. Но жалеть не стоит – как я уже сказал, кроме головной боли, ничего иного Вы там не заработаете.
Есть еще один интересный факт, касающийся непосредственно системы 1С:Франчайзинга. Мы в своей компании всегда старались и стараемся поддерживать квалификацию сотрудников, как тех, которые занимаются прикладным программным обеспечением, так и тех, кто занимается системным ПО и аппаратной частью на достаточно высоком уровне. Такой подход, в общем, затрудняет работу – больше затраты на обучение и повышение квалификации, меньше «вал» выполненных (вернее наполовину выполненных или «криво» выполненных) заказов и т.д. Так вот, в последнее время на удивление легко стало договариваться с клиентами, у которых уже побывали сотрудники других фирм-франчайзи. В первую очередь это касается «кривых» недоделанных сетевых установок, недоустановленных обоновлений и апгрейдов на 2000 год, различных сетевых заморочек и т.п. Это не означает, что у нас все получается с первого раза, и по высшему разряду. Но если мы взялись за какую-то недоделанную другими задачу, то стараемся выполнить ее, во что бы то ни стало. И оплату берем за результат, а не за проведенное у клиента время. В конечном итоге – пополнение количества абонементных клиентов. Наилучшей рекомендацией, как оказалось, является не просто выполненная работа, а выполненная работа, которую не смогли выполнить другие.
Итак, какие же выводы можно сделать из всего сказанного. Главный вывод – у руководства потенциальных клиентов сохраняется «посткризисный» синдром, чему в немалой степени способствует огромный рынок незадействованной рабочей силы в той или иной степени знакомой с компьютером. Кризис сумели пережить только те предприятия, руководители которых вели жесткую финансовую политику, экономили каждую копейку. Продолжают они экономить и сейчас, хотя вполне могут позволить себе расслабиться. Пройдет еще немало времени, пока станет очевидным, что политика жесткой экономии, позволившая пережить кризис, стала теперь тормозом в развитии. Соответствует ситуации и положение внедренческих контор, которым приходится прилагать довольно значительные усилия не на разработку собственно заказа, а на «разработку» руководства предприятия-клиента, т.е. больше внимания уделяется вопросам нахождения и удержания клиента, а не самому внедрению, что естественно сказывается на качестве выполняемых работ. Вероятно, пройдет еще некоторое время, пока сменится поколение руководителей потенциальных заказчиков, а внедренцы найдут оптимальный баланс между маркетинговой деятельностью и техническим уровнем непосредственных исполнителей. Это непременно должно произойти в ближайшие 2-3 года. Если не будет нового кризиса…
ПЗ.1. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания
Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях (далее организациях). Стандарт устанавливает стадии и этапы создания AC, a также содержание работ на каждом этапе.
Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. Стадии и этапы создания АС в общем случае приведены ниже.
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС
2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских работ
2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание
Разработка и утверждение технического задания на создание АС
4. Эскизный проект
4.1 Разработка предварительных проектных решений по системе и ее частям
4.2. Разработка документации на АС и ее части
5. Технический проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее части
6.2. Разработка или адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации к вводу АС в действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
7.4. Строительно-монтажные работы
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными обязательствами
8.2. Послегарантийное обслуживание
Допускается исключать стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
На этапе 1.1 в общем случае проводят сбор данных об объекте автоматизации и осуществляемых видах деятельности; оценку качества функционирования объекта и осуществляемых видов деятельности, выявление проблем, решение которых возможно средствами автоматизации; оценку (технико-экономической, социальной и т. п.) целесообразности создания АС.
На этапе 1.2 проводят подготовку исходных данных для формирования требований к АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы); формулировку и оформление требований пользователя к АС.
На этапе 1.3 проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого замещающего ее документа с аналогичным содержанием.
На этапах 2.1 и 2.2 организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчеты о НИР.
На этапе 2.3 в общем случае проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; сопоставление требований пользователя и характеристик предлагаемой системы и выбор оптимального варианта; определение порядка оценки качества и условий приемки системы; оценку эффектов, получаемых от системы.
На этапе 2.4 подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии, описание и обоснование предлагаемого варианта концепции системы.
На этапе 3.1 проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.
На этапе 4.1 определяются функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.
На этапе 5.1 обеспечивают разработку общих решений по системе и ее частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решений задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению.
На этапах 4.2 и 5.2 проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС.
На этапе 6.1 осуществляют разработку рабочей документации, одержащей все необходимые и достаточные сведения для
обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение.
На этапе 6.2 проводят разработку программ и программных средств системы, выбор, адаптацию и/или привязку приобретаемых программных средств, разработку программной документации.
На этапе 7.1 проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.
На этапе 7.2 проводят обучение персонала и проверку его способности обеспечить функционирование АС.
На этапе 7.6 осуществляют испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний; устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний; оформление акта о приемке АС в опытную эксплуатацию.
На этапе 7.7 проводят опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.
На этапе 7.8 проводят испытание на соответствие техническому заданию в соответствии с программой и методикой приемочных испытаний; анализ результатов испытаний АС и устранение недостатков, выявленных при испытаниях; оформление акта о приемке АС в постоянную эксплуатацию.
На этапе 8.1 осуществляют работы по устранению недостатков, выявленных при эксплуатации АС в течение установленных гарантийных сроков, внесению необходимых изменений в документацию на АС.
На этапе 8.2 осуществляют работы по анализу функционирования системы; выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений; установлению причин этих отклонений; устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС; внесению необходимых изменений в документацию на АС.
ПЗ.2. РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т.п.), включая их сочетание, и устанавливают требования к содержанию док ументов, разрабатываемых при создании АС.
Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы. Содержание каждого документа определяет разработчик в зависимости от объекта проектирования (системы, подсистема и т.д.).
1. Пояснительные записки к эскизному, техническому проектам содержат разделы: общие положения; описание процесса деятельности;
основные технические решения; мероприятия по подготовке объекта автоматизации к вводу системы в действие.
В разделе "Общие положения" приводят:
• наименование проектируемой АС и наименования документов, их номера и дату утверждения, на основании которых ведут проектирование АС;
• перечень организаций, участвующих в разработке системы, сроки выполнения стадий;
• цели, назначение и области использования АС;
• подтверждение соответствия проектных решений действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности и т.п.;
• сведения об использованных при проектировании нормативно-технических документах;
• сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта;
• очередность создания системы и объем каждой очереди.
В разделе "Описание процесса деятельности"
• отражают состав процедур (операций) с учетом обеспечения взаимосвязи и совместимости процессов автоматизированной и неавтоматизированной деятельности;
• формируют требования к организации работ в условиях функционирования АС.
В разделе "Основные технические решения" приводят:
• решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы, подсистем;
• решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости;
• решения по режимам функционирования, диагностированию работы системы;
• решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку взаимодействия;
• сведения об обеспечении заданных в техническом задании (ТЗ) потребительских характеристик системы (подсистем), определяющих ее качество;
• состав функций, комплексов задач, реализуемых системой (подсистемой);
• решения по комплексу технических средств, его размещению на объекте;
• решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам;
• решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации.
В разделе "Мероприятия по подготовке объекта автоматизации к вводу системы в действие" приводят:
• мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
• мероприятия по обучению и проверке квалификации персонала;
• мероприятия по созданию необходимых подразделений и рабочих мест;
• мероприятия по изменению объекта автоматизации;
• другие мероприятия, исходящие из специфических особенностей создаваемых АС.
2. Схема функциональной структуры содержит:
• элементы функциональной структуры АС (подсистемы АС);
автоматизированные функции и/или задачи (комплексы задач);
совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком;
• информационные связи между элементами и с внешней средой с кратким указанием содержания сообщений и/или сигналов, передаваемых по связям, и при необходимости, связи других типов (входимости, подчинения и т. д.);
• детализированные схемы частей функциональной структуры (при необходимости).
3. Описание автоматизируемых функций содержит разделы: исходные данные; цели АС и автоматизированные функции; характеристика функциональной структуры; типовые решения (при наличии).
В разделе "Исходные данные" приводят:
• перечень исходных материалов и документов, использованных при разработке функциональной части проекта АС;
• особенности объекта управления, влияющие на проектные решения по автоматизированным функциям;
• данные о системах управления, взаимосвязанных с разрабатываемой АС, и сведения об информации, которой она должна обмениваться с абонентами и другими системами;
• описание информационной модели объекта вместе с его системой управления.
В разделе "Цели АС и автоматизированные функции" приводят описание автоматизированных функций, направленных на достижение установленных целей.
Раздел "Характеристика функциональной структуры" содержит:
• перечень подсистем АС с указанием функций и/или задач, реализуемых в каждой подсистеме;
• описание процесса выполнения функций (при необходимости);
• необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком;
•требования к временному регламенту и характеристикам процесса реализации автоматизированных функций (точности, надежности и т.п.) и решения задач.
В разделе "Типовые решения" приводят перечень типовых решений с указанием функций, задач, комплексов задач, для выполнения которых они применены.
4. Описание постановки задачи (комплекса задач) содержит разделы: характеристики комплекса задач; выходная информация; входная информация.
В разделе "Характеристики комплекса задач" приводят:
• назначение комплекса задач;
• перечень объектов (технологических объектов управления, подразделений предприятия и т. п.), при управлении которыми решают комплекс задач;
• периодичность и продолжительность решения;
•условия, при которых прекращается решение комплекса задач автоматизированным способом (при необходимости);
• связи данного комплекса задач с другими комплексами (задачами) АС;
• должности лиц и/ или наименования подразделений, определяющих условия и временные характеристики конкретного решения задачи (если они не определены общим алгоритмом функционирования системы);
• распределение действий между персоналом и техническими средствами при различных ситуациях решения комплекса задач.
Раздел "Выходная информация" содержит:
• перечень и описание выходных сообщений;
• перечень и описание имеющих самостоятельное смысловое значение структурных единиц информации выходных сообщений (показателей, реквизитов и их совокупностей, сигналов управления) или ссылку на документы, содержащие эти данные.
В описании по каждому выходному сообщению следует указывать:
• идентификатор;
• форму представления сообщения (документ, видеокадр, сигнал управления) и требования к ней;
• периодичность выдачи;
• сроки выдачи и допустимое время задержки решения;
• получателей и назначение выходной информации. В описании по каждой структурной единице информации следует указывать:
• наименование;
• идентификатор выходного сообщения, содержащего структурную единицу информации;
• требования к точности и надежности вычисления (при необходимости).
Раздел "Входная информация" должен содержать:
•перечень и описание входных сообщений (идентификатор, форму представления, сроки и частоту поступления);
•перечень и описание структурных единиц информации входных сообщений или ссылку на документы, содержащие эти данные.
В описании по каждой структурной единице информации входных сообщений следует указывать:
• наименование;
• требуемую точность ее числового значения (при необходимости);
• источник информации (документ, видеокадр, устройство, кодограмма, информационная база на машинных носителях и т. д.);
• идентификатор источника информации.
5. Общее описание системы содержит разделы: назначение системы; описание системы; описание взаимосвязей АС с другими системами; описание подсистем (при необходимости).
В разделе "Назначение системы" указывают:
• вид деятельности, для автоматизации которой предназначена система;
• перечень объектов автоматизации, на которых используется система;
• перечень функций, реализуемых системой. В разделе "Описание системы" указывают:
• структуру системы и назначение ее частей;
• сведения об АС в целом и ее частях, необходимые для обеспечения эксплуатации системы;
• описание функционирования системы и ее частей.
В разделе "Описание взаимосвязей АС с другими системами" указывают:
• перечень систем, с которыми связана данная АС;
• описание связей между системами;
• описание регламента связей;
• описание взаимосвязей АС с подразделениями объекта автоматизации.
В разделе "Описание подсистем" указывают:
• структуру подсистем и назначение ее частей;
• сведения об подсистемах и их частях, необходимые для обеспечения их функционирования;
• описание функционирования подсистем и их частей.
6. Программа и методика испытаний должна содержать перечни конкретных проверок (решаемых задач), которые следует осуществлять при испытаниях для подтверждения выполнения требований ТЗ, со ссылками на соответствующие методики (разделы методик) испытаний. Перечень проверок, подлежащих включению в программу испытаний, включает:
• соответствие системы ТЗ;
• комплектность системы;
• комплектность и качество документации;
• комплектность, достаточность состава и качество программных средств и программной документации;
• количество и квалификация обслуживающего персонала;
• степень выполнения требований функционального назначения системы;
• контролепригодность системы;
• выполнение требований техники безопасности, противопожарной безопасности, промышленной санитарии, эргономики;
• функционирование системы с применением программных средств.
Программа испытаний содержит разделы: объект испытаний; цель испытаний; общие положения; объем испытаний; условия и порядок проведения испытаний; материально-техническое обеспечение испытаний; метрологическое обеспечение испытаний; отчетность.
В разделе " Объект испытаний" указывают: полное наименование системы, обозначение; комплектность испытательной системы.
В разделе "Цель испытаний" указывают конкретные цели и задачи, которые должны быть достигнуты и решены в процессе испытаний.
В разделе "Общие положения" указывают:
• перечень руководящих документов, на основании которых проводят испытания;
• место и продолжительность испытаний;
• организации, участвующие в испытаниях;
• перечень ранее проведенных испытаний;
• перечень предъявляемых на испытания документов, откорректированных по результатам ранее проведенных испытаний.
В разделе "Объем испытаний" указывают:
• перечень этапов испытаний и проверок, а также количественные и качественные характеристики, подлежащие оценке;
• последовательность проведения и режимы испытаний;
• требования по испытаниям программных средств;
• перечень работ, проводимых после завершения испытаний, требования к ним, объем и порядок проведения.
В разделе "Условия и порядок проведения испытаний" указывают:
• условия проведения испытаний;
• условия начала и завершения отдельных этапов испытаний;
• имеющиеся ограничения в условиях проведения испытаний;
• требования к техническому обслуживанию системы;
• меры, обеспечивающие безопасность и безаварийность проведения испытаний;
• порядок взаимодействия организаций, участвующих в испытаниях;
• порядок привлечения экспертов для исследования возможных повреждений в процессе проведения испытаний;
• требования к персоналу, проводящему испытания, и порядок его допуска к испытаниям.
7. Схема организационной структуры содержит:
• состав подразделений (должностных лиц) организации, обеспечивающих функционирование АС либо использующих при принятии решения информацию, полученную от АС;
• основные функции и связи между подразделениями и отдельными должностными лицами, указанными на схеме, и их подчиненность.
8. Описание организационной структуры содержит разделы изменения в организационной структуре управления объектом организация подразделений; реорганизация существующие подразделений управления. В разделе "Изменения в организационной структуре управления объектом" указывают проектные решения по изменению организационной структуры управления объектом и их обоснование; описание изменений во взаимосвязях между подразделениями. В разделе "Организация подразделений" приводят: описание организационной структуры и функций подразделений, создаваемых с целью обеспечения функционирования АС; описание регламента работ; перечень категорий работников и число штатных единиц. В разделе "Реорганизация существующих подразделений управления" указывают описание изменений, обусловленных созданием АС, которые необходимо осуществить в каждом из действующих подразделений управления объектом в организационной структуре, функциях подразделений, регламенте работы, составе персонала подразделений.
9. Методика автоматизированного проектирования содержит разделы: общие положения; постановка задачи; методика проектирования; исходные данные; проектные процедуры; оценка результатов. В разделе "Общие положения" указывают класс объектов, на которые распространена методика, состав специалистов-пользователей, требования и ограничения на условия применения методики. В разделе "Постановка задачи" указывают основные пути и направления решения задачи, требования и ограничения на решение, критерии оценки результатов. В разделе "Методика проектирования" описывают выбранные математические методы, используемые при проектировании, указывают состав и назначение проектных процедур, порядок взаимодействия проектных процедур в процессе выполнения. В разделе "Исходные данные" определяют состав, порядок выбора, представления и формирования массивов используемой информации, перечень обозначений элементов, описывающих предметную область, с указанием их наименований, единиц измерений, диапазона изменения значений, критерии оценки исходных данных, выбирают методы и модели решения. В разделе "Проектные процедуры" указывают по каждой проектной процедуре состав нормативно-справочных входных данных, правила доступа к ним, порядок выполнения процедуры, состав и форму выходных сообщений. В разделе "Оценка результатов" приводят анализ полученного проектного решения на соответствие заданным критериям.
10. Перечень входных сигналов и данных содержит разделы: перечень входных сигналов; перечень входных данных.
В разделе "Перечень входных сигналов" указывают:
• для аналогового сигнала - наименование измеряемой величины, единицы измерения, диапазон изменения, требования точности и периодичности измерения, тип сигнала;
• для дискретного сигнала - наименование, разрядность и периодичность, тип сигнала;
• для сигнала "да-нет" - источник формирования и смысловое значение сигнала.
В разделе "Перечень входных данных" указывают:
• наименование, кодовое обозначение и значность реквизитов входных данных;
• наименования и кодовые обозначения документов или сообщений, содержащих эти данные.
11. Перечень выходных сигналов (документов) содержит разделы: перечень выходных сигналов; перечень выходных документов. Раздел "Перечень выходных сигналов" содержит перечень выходных сигналов с указанием их наименований, назначения, единиц измерения и диапазонов изменения, способа представления, пользователей информации. Раздел "Перечень выходных документов" содержит перечень выходных документов с указанием их наименований, кодовых обозначений, перечня и значности реквизитов, пользователей информации.
12. Описание информационного обеспечения системы содержит разделы: состав информационного обеспечения; организация информационного обеспечения; организация сбора и передачи информации; построение системы классификации и кодирования; организация внутримашинной информационной базы; организация внемашинной информационной базы.
В разделе "Состав информационного обеспечения" указывают наименование и назначение всех баз данных и наборов данных.
В разделе "Организация информационного обеспечения" приводят:
• принципы организации информационного обеспечения системы;
• обоснование выбора носителей данных и принципы распределения информации по типам носителей;
• описание принятых видов и методов контроля в маршрутах обработки данных при создании и функционировании внемашинной и внутримашинной информационных баз с указанием требований, на соответствие которым проводят контроль;
• описание решений, обеспечивающих информационную совместимость АС с другими системами управления по источникам, потребителям информации, по сопряжению применяемых классификаторов (при необходимости), по использованию в АС унифицированных систем документации.
В разделе "Организация сбора и передачи информации" приводят:
• перечень источников и носителей информации с указанием оценки интенсивности и объема потоков информации;
• описание общих требований к организации сбора, передачи, контроля и корректировки информации.
В разделе "Построение системы классификации и кодирования" приводят:
• описание принятых для применения в АС классификаций объектов во вновь разработанных классификаторах и в тех действующих классификаторах, из которых используется часть кода;
• методы кодирования объектов классификации во вновь разработанных классификаторах.
В разделе "Организация внутримашинной информационной базы" приводят:
• описание принципов построения внутримашинной информационной базы, характеристики ее состава и объема;
• описание структуры внутримашинной информационной базы на уровне баз данных с описанием характера взаимосвязей баз данных и указанием функций АС, при реализации которых используют каждую базу данных, характеристики данных, содержащихся в каждой базе данных.
В разделе "Организация внемашинной информационной базы" приводят характеристики состава и объема внемашинной информационной базы, принципы ее построения, в том числе основные положения по организации и обслуживанию фонда нормативно-справочной информации во взаимосвязи с автоматизированными функциями.
13. Описание организации информационной базы содержит описание логической и физической структуры базы данных и состоит из двух частей: описание внутримашинной информационной базы; описание внемашинной информационной базы. Части документа содержат следующие разделы: логическая структура; физическая структура (для внутримашинной информационной базы); организация ведения информационной базы. В разделе "Логическая структура" приводят описание состава данных, их форматов и взаимосвязей между данными. В разделе "Физическая структура" приводят описание избранного варианта расположения данных на конкретных машинных носителях. При описании структуры внутримашинной информационной базы должны быть приведены перечни баз данных и массивов и логические связи между ними. Для массива информации указывают логическую структуру внутри массива или дают ссылку на документ "Описание массива информации". При описании структуры внемашинной информационной базы приводят перечень документов и других информационных сообщений, использование которых предусмотрено в системе, с указанием автоматизируемых функций, при реализации которых формируют или используют данный документ. В разделе "Организация ведения информационной базы" при описании внутримашинной базы приводят последовательность процедур при создании и обслуживании базы с указанием, при необходимости, регламента выполнения процедур и средств защиты базы от разрушения и несанкционированного доступа, а также с указанием связей между массивами баз данных и массивами входной информации. При описании внемашинной информационной базы должна быть приведена последовательность процедур по маршруту движения групп документов до передачи их на ВЦ, а также описан маршрут движения выходных документов.
14. Описание систем классификации и кодирования содержит перечень применяемых в АС зарегистрированных классификаторов всех категорий по каждому классифицируемому объекту, описание метода кодирования, структуры и длины кода, указания о системе классификации и другие сведения по усмотрению разработчика.
15. Описание массива информации содержит:
• наименование массива;
• обозначение массива;
• наименование носителей информации;
• перечень реквизитов в порядке их следования в записях массива с указанием по каждому реквизиту: обозначения алфавита, длины в знаках и диапазона изменения (при необходимости), логических и семантических связей с другими реквизитами данной записи и другими записями массива;
• оценку объема массива;
• другие характеристики массива (при необходимости).
16. Отчет по ГОСТ 7.32 на стадии "Формирование требований к АС" содержит разделы:
• характеристика объекта и результатов его функционирования;
• описание существующей информационной системы;
• описание недостатков существующей информационной системы;
• обоснование необходимости совершенствования информационной системы объекта;
• цели, критерии и ограничения создания АС;
• функции и задачи создаваемой АС;
• выводы и предложения.
В разделе "Характеристика объекта и результатов его функционирования" описывают тенденции развития, требования к объему, номенклатуре и качеству результатов функционирования, а также характер взаимодействия объекта с внешней средой. Раздел "Описание существующей информационной системы" содержит описание функциональной и информационной структуры системы, качественных и количественных характеристик, раскрывающих взаимодействие ее компонентов в процессе функционирования. В разделе "Описание недостатков существующей информационной системы" приводят результаты диагностического анализа, при котором оценивают качество функционирования и организационно-технологический уровень системы, выявляют недостатки в организации и технологии функционирования информационных процессов и определяют степень их влияния на качество функционирования системы. В разделе "Обоснование необходимости совершенствования информационной системы объекта" при анализе соответствия показателей функционирования объекта предъявляемым требованиям оценивают степень соответствия прогнозируемых показателей требуемым, а также выявляют необходимость совершенствования информационной системы путем создания АС. Раздел "Цели, критерии и ограничения создания АС" содержит: формулировку производственно-хозяйственных, научно- технических и экономических целей и критериев создания АС; характеристику ограничений по созданию АС.
Раздел "Функции и задачи создаваемой АС" содержит:
• обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения;
• требования к характеристикам реализации функций и задач в соответствии с действующими нормативно-техническими документами, определяющими общие технические требования к АС конкретного вида;
• дополнительные требования к АС в целом и ее частям, учитывающие специфику создаваемой АС.
Раздел "Ожидаемые технико-экономические результаты создания АС" содержит:
• перечень основных источников экономической эффективности получаемых в результате создания АС (в том числе – экономия производственных ресурсов, улучшение качества продукции, повышение производительности труда и т. д.) и оценку ожидаемых изменений основных технико-экономических и социальных показателей производственно-хозяйственной деятельности объекта (например, показателей по номенклатуре и объемам производства, себестоимости продукции, рентабельности, отчислениям в фонд экономического стимулирования, уровню социального развития);
• оценку ожидаемых затрат на создание и эксплуатацию АС с распределением их по очередям создания АС и по годам;
• ожидаемые обобщающие показатели экономической эффективности АС.
Раздел "Выводы и предложения" рекомендуется разделять на подразделы: выводы о производственно-хозяйственной необходимости и технико-экономической целесообразности создания АС; предложения по совершенствованию организации и технологии процесса деятельности; рекомендации по созданию АС. одраздел "Выводы о производственно-хозяйственной необходимости и технико-экономической целесообразности создания АС" содержит: сопоставление ожидаемых результатов создания АС с заданными целями и критериями создания АС (по целевым показателям и нормативным требованиям); принципиальное решение вопроса о создании АС (положительное или отрицательное). Подраздел "Предложения по совершенствованию организации и технологии процесса деятельности" содержит предложения по совершенствованию: производственно-хозяйственной деятельности; организационной и функциональной структур системы, методов деятельности, видов обеспечения АС. Подраздел "Рекомендации по созданию АС" содержит рекомендации:
• по виду создаваемой АС, ее совместимости с другими АС и неавтоматизируемой частью соответствующей системы;
• по организационной и функциональной структуре создаваемой АС;
• по составу и характеристикам подсистем и видов обеспечения АС;
• по организации использования имеющихся и приобретению дополнительных средств вычислительной техники;
• по рациональной организации разработки и внедрения АС;
• по определению основных и дополнительных, внешних и внутренних источников и видов объемов финансирования и материального обеспечения разработок АС;
• по обеспечению производственных условий создания АС;
• другие рекомендации по созданию АС.
17. Отчет по ГОСТ 7.32 на стадии "Разработка концепции АС" содержит:
• описание результатов изучения объекта автоматизации;
• описание и оценку преимуществ и недостатков разработанных альтернативных вариантов концепции создания АС;
• сопоставительный анализ требований пользователя к АС и вариантов концепции АС на предмет удовлетворения требованиям пользователя;
• обоснование выбора оптимального варианта концепции и описание предлагаемой АС;
• ожидаемые результаты и эффективность реализации выбранного варианта концепции АС;
• ориентировочный план реализации выбранного варианта концепции АС;
• необходимые затраты ресурсов на разработку, ввод в действие и обеспечение функционирования;
• требования, гарантирующие качество АС;
• условия приемки системы.
ПЗ.3. ГОСТ 234.003-90. Автоматизированные системы. Термины и определения
Настоящий стандарт устанавливает термины и определения основных понятий в области автоматизированных систем (АС) и распространяется на АС, используемые в различных сферах деятельности (управление, исследования, проектирование и т.п., включая их сочетание), содержанием которых является переработка информации.
Автоматизированная система. Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
Интегрированная АС. Совокупность двух или более взаимоувязанных АС, в которой функционирование одной из них зависит от результатов функционирования другой (других) так, что эту совокупность можно рассматривать как единую АС.
Функция АС. Совокупность действий АС, направленная на достижение определенной цели.
Алгоритм функционирования АС. Алгоритм, задающий условия и последовательность действий компонентов автоматизированной системы при выполнении ею своих функций.
Пользователь АС. Лицо, участвующее в функционировании АС или использующее результаты ее функционирования.
Организационное обеспечение АС. Совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала АС в условиях функционирования, проверки и обеспечения работоспособности АС.
Методическое обеспечение АС. Совокупность документов, описывающих технологию функционирования АС, методы выбора и применения пользователями технологических приемов для получения конкретных результатов при функционировании АС.
Техническое обеспечение АС. Совокупность всех технических средств, используемых при функционировании АС.
Математическое обеспечение АС. Совокупность математических методов, моделей и алгоритмов, примененных в АС.
Программное обеспечение АС. Совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС.
Информационное обеспечение АС. Совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании.
Лингвистическое обеспечение АС. Совокупность средств и правил для формализации естественного языка, используемых при общении и пользователей и эксплуатационного персонала АС с комплексом средств автоматизации при функционировании АС.
Правовое обеспечение АС. Совокупность правовых норм, регламентирующих правовые отношения при функционировании АС и юридический статус результатов ее функционирования.
Эргономическое обеспечение АС. Совокупность реализованных решений в АС по согласованию психологических, психофизиологических, антропометрических, физиологических характеристик и возможностей пользователей АС с техническими характеристиками комплекса средств автоматизации АС и параметрами рабочей среды на рабочих местах персонала АС.
Компонент АС – часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое.
Информационная база АС. Совокупность упорядоченной информации, используемой при функционировании АС.
Внемашинная информационная база АС. Часть информационной базы АС, представляющая собой совокупность документов, предназначенных для непосредственного восприятия человеком без применения средств вычислительной техники.
Машинная информационная база АС. Часть информационной базы АС, представляющая собой совокупность используемой в АС информации на носителях данных.
Автоматизированное рабочее место (АРМ). Программно-технический комплекс АС, предназначенный для автоматизации деятельности определенного вида.
Эффективность АС. Свойство АС, характеризуемое степенью достижения целей, поставленных при ее создании.
Совместимость АС. Комплексное свойство двух или более АС, характеризуемое их способностью взаимодействовать при функционировании (включающее техническую, программную, информационную, организационную и лингвистическую совместимость).
Адаптивность АС. Способность АС изменяться для сохранения своих эксплуатационных показателей в заданных пределах при изменениях внешней среды.
Надежность АС. Комплексное свойство АС сохранять во времени в установленных пределах значения всех параметров, характеризующих способность АС выполнять свои функции в заданных режимах и условиях эксплуатации.
Живучесть АС. Свойство АС, характеризуемое способностью выполнять установленный объем функций в условиях воздействий внешней среды и отказов компонентов системы в заданных пределах.
Жизненный цикл АС. Совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС.
Сопровождение АС. Деятельность по оказанию услуг, необходимых для обеспечения устойчивого функционирования или развития АС.
Диалоговый режим выполнения функции АС. Режим выполнения функции АС, при котором человек управляет решением задачи, изменяя ее условия и/или порядок функционирования АС на основе оценки информации, представляемой ему техническими средствами АС.
Техническое задание на АС. Документ, оформленный в установленном порядке и определяющий цели создания АС, требования к АС и основные исходные данные, необходимые для ее разработки, а также план-график создания АС.
Технический проект АС. Комплект проектных документов на АС, разрабатываемый на стадии "Технический проект", утвержденный в установленном порядке, содержащий основные проектные решения по
системе в целом, ее функциям и всем видам обеспечения АС и достаточный для разработки рабочей документации на АС.
Рабочая документация на АС. Комплект проектных документов на АС, разрабатываемый на стадии "Рабочая документация", содержащий взаимоувязанные решения по системе в целом, ее функциям, всем видам обеспечения АС, достаточные для комплектации, монтажа, наладки и функционирования АС, ее проверки и обеспечения работоспособности.
Эксплуатационная документация на АС. Часть рабочей документации на АС, предназначенная для использования при эксплуатации системы, определяющая правила действия персонала и пользователей системы при ее функционировании, проверке и обеспечении ее работоспособности.
Технорабочий проект АС. Комплект проектных документов АС, утвержденный в установленном порядке и содержащий решения в объеме технического проекта и рабочей документации на АС.
Входная информация АС. Информация, поступающая в АС в виде документов, сообщений, данных, сигналов, необходимая для выполнения функций АС.
Выходная информация АС. Информация, получаемая в результате выполнения функций АС и выдаваемая на объект ее деятельности, пользователю или в другие системы.
Нормативно-справочная информация АС. Информация, заимствованная из нормативных документов и справочников и используемая при функционировании АС.
РАБОЧИЙ ПЛАН ПРОЕКТА ВНЕДРЕНИЯ
| 1 | 01 | Постановка задачи | |||
| 1.1 | 01-ПП | Планирование проекта | |||
| 1.1.1 | 01-ПП-НАЧ | Начать планирование проекта | |||
| 1.1.2 | 01-УО-010 | Установить область рассмотрения, цели и подход к реализации проекта | Обяз | Начальная версия плана управления проектом | |
| 1.1.3 | 01-УО-020 | Определить стратегию, стандарты и процедуры контроля и отчетности | Стратеги, … | ||
| 1.1.4 | 01-УО-030 | Составить планы управления | План управления проектом (суммирует результаты предыдущих задач) | ||
| 1.1.5 | 01-УР-010 | Определить стратегию, стандарты и процедуры управления работами | Стратегия, стандарты и процедуры управления работами | ||
| 1.1.6 | 01-УР-020 | Составить рабочий план проекта | Обяз. | Док. | Рабочий план проекта |
| 1.1.7 | 01-УР-030 | Составить финансовый план проекта | Обяз. | Док. | Финансовый план проекта |
| 1.1.8 | 01-УС-010 | Определить стратегию, стандарты и процедуры управления ресурсами | Стратегию, стандарты и процедуры управления ресурсами | ||
| 1.1.9 | 01-УС-020 | Составить организационно-кадровый план | Обяз. | Док. | Организационно-кадровый план |
| 1.1.10 | 01-УС-025 | Создать руководство по административным процедурам для членов группы проекта | Обяз. | Док. | Руководство … |
| 1.1.11 | 01-УС-030 | Создать организационную структуру проекта | Обяз. | Док: | Укомплектованная кадрами организационная структура проекта |
| 1.1.12 | 01-УС-040 | Принять план физических ресурсов (необходимых сверх существующей инфраструктуры) | План физических ресурсов | ||
| 1.1.13 | 01-УС-050 | Подготовить инфраструктуру проекта | Обяз. | Док. | Готовая инфраструктура проекта |
| 1.1.14 | 01-УК-010 | Определить стратегию, стандарты и процедуры управления качеством | Стратегия, … | ||
| 1.1.15 | 01-УФ-010 | Определить стратегию, стандарты и процедуры управления конфигурацией | Стратегия, … | ||
| 1.1.16 | 01-ПП-КОН | Закончить планирование проекта | |||
| 1.2 | 01-БП | Моделирование бизнес-процессов | |||
| 1.2.1.,. | 01-ФВ-НАЧ | Начать выполнение фазы | |||
| 1.2.2. | 01-БП-010 | Определить стратегию развития бизнеса и улучшения бизнес-процессов | Стратегия совершенствования бизнеса | ||
| 1.2.3 | 01-БП-020 | Подготовить аналитический обзор требуемых изменении | Аналитический обзор требуемых изменений | ||
| 1,2.4^, | 01-БП-030 | Определить требования к исходным данным, условиям и порядку их получения | Обяз. | Док. | Требования к исходным данным |
| 1.2.5 | 01-БП-040 | Построить модель существующих процессов | Обяз. | Модель существующих процессов | |
| 1.2.е^ | 01-БП-050 | Проанализировать примененимость передового опыта | Оценка применимости передового опыта | ||
| 1.2.7': | 01-БП-060 | Подготовить видение процессов в новых условиях | Обяз. | ?Док. | Видение процессов в новых условиях |
| 1.2.8 | 01-БП-070 | Выполнить высокоуровневое проектирование процессов | Высокоуровневый проект процессов | ||
| 1.3 | 01-БТ | Определение бизнес-требований | |||
| 1.3.1 | 01-БТ-010 | Обследовать текущую финансовую и операционную структуру | Обяз. | Описание текущей … | |
| 1.3.2 | 01-БТ-020 | Определить базовые показатели текущего состояния предприятия | Обяз. | Базовые … | |
| 1.4 | 01-ТА |
Работа с таблицами
Предметом рассмотрения в данной главе являются таблицы — основной объект Access. Список таблиц, составляющих базу данных приложения, появляется в окне базы данных при первом открытии приложения. Кроме этого, Access создает системные таблицы, в которых хранится информация обо всех объектах приложения, и эти таблицы при необходимости также могут отображаться в окне базы данных.
В данной главе мы остановимся на двух важнейших аспектах работы с таблицами:
описание структуры таблиц и установка связи между ними;
работа с данными в таблицах: ввод, просмотр, изменение, поиск и т. д.
При описании структуры таблиц мы будем опираться на те сведения из теории баз данных, которые были приведены в начале предыдущей главы, и по мере необходимости дополнять их. Этого будет достаточно для понимания излагаемого материала.
В настоящей главе будут рассмотрены:
Различные способы создания таблиц, которые предоставляет Access
Определение полей в таблице, свойства полей, а также свойства самих таблиц
Способы, с помощью которых можно задать условия проверки корректности ввода данных на уровне поля и на уровне записи
Определение ключевых полей, установка связей между таблицами, работа со схемой данных Создание и использование индексов
Способы добавления, обновления, замены и удаления записей при работе с таблицами
Способы сортировки данных в таблице
Возможности поиска записей по значению поля, а также замены вхождений образца в поле
Способы отбора данных при помощи фильтров, копирования, экспорта и рассылки отсортированных и отфильтрованных данных
Работа с записями
Работа с записями
Рассмотрим работу с записями в режиме Таблицы. Существуют три операции с записями: добавление записи, изменение записи и удаление записи. Чтобы добавить в таблицу новую запись, необходимо нажать кнопку Новая запись (New Record) на панели инструментов Таблица (Table Datasheet), а затем ввести данные в поля новой записи. Возможно также использование одного из следующих вариантов добавления записи в таблицу.
Нажать кнопку добавления новой записи >* в нижней части окна таблицы.
Переместить указатель на запись, отмеченную в области выделения звездочкой.
Выбрать в главном меню команду Вставка, Новая запись (Insert, New Record).
Щелкнуть правой кнопкой мыши на области выделения и из контекстного меню выбрать команду Новая запись (New Record).
Замечание
Microsoft Access сохраняет изменения в полях текущей записи при переходе к другой записи.
Замечание
Если нужно внести изменения сразу в несколько записей, например увеличить цены в прайс-листе на некоторый коэффициент, используется запрос к базе данных специального вида — запрос на обновление (см. гл. 8).
-
Выделить одну или несколько записей для копирования или перемещения.
Выделение записей выполняется аналогично тому, как это делается в электронной таблице, т. е. щелкните левой кнопкой мыши в области выделения первой записи и, удерживая кнопку, переместите указатель мыши до последней выделяемой записи, затем отпустите кнопку. Аналогично выделяются столбцы таблицы, только щелкать мышью нужно по области заголовка столбца.
-
Для того чтобы скопировать записи — нажать на панели инструментов кнопку
Копировать
(Сору).
Для того чтобы переместить записи — нажать на панели инструментов кнопку Вырезать (Cut).
Открыть в режиме Таблицы объект, в который требуется скопировать записи. При необходимости, переставить столбцы, чтобы они соответствовали порядку копируемых или перемещаемых данных.
Для замены существующих записей копируемыми — выделить заменяемые записи и нажать на панели инструментов кнопку Вставить (Paste).
Для добавления записей в конец таблицы — выбрать в меню Правка (Edit) команду Добавить из буфера (Paste Append).
Удалить запись можно тоже несколькими способами. Сначала нужно в любом случае выделить запись, а затем выполнить одно из следующих действий:
Нажать на панели инструментов кнопку Удалить запись (Delete Record).
Щелкнуть правой кнопкой мыши на области выделения удаляемых записей и из контекстного меню выбрать команду Удалить запись (Delete Record).
Выбрать из меню Правка (Edit) команду Удалить (Delete) или Удалить запись (Delete Record).
Нажать клавишу Удалить (Delete).
При удалении записей Access запрашивает подтверждение, чтобы предотвратить случайное удаление (рис. 2.34).
Распределение обращений по профилю
После того, как принято решение о том, что мы будем выполнять работы у данного клиента, необходимо распределить работу между специализированными подразделениями (или сотрудниками) компании. При таком распределении следует считать «профилем» не только отраслевую специфику (например, автоматизация автотранспортных предприятий, компаний, занимающихся работой, с ценными бумагами), но и распределение по компонентам системы программ «1С:Предприятие».
Очевидно, что специализированное подразделение (сотрудник) компании должен получать профильный заказ в первую очередь.
Рассматривая специализацию сотрудников по компонентам необходимо помнить о том, что очень неплохо иметь сотрудников, которые знают несколько продуктов. Тогда в периоды пиковой нагрузки для какого-либо продукта (это начало и конец года для «1С:Зарплата и кадры», конец квартала для «1С:Бухгалтерии» и т.д.) можно будет переориентировать такого рода универсалов на соответствующий продукт и тем самым обеспечивать клиентов услугами.
Комплексная автоматизация
Принимая решение о комплексной автоматизации предприятия нужно в обязательном порядке решить для себя ряд вопросов:
кто будет создавать техническое задание?
кто будет руководить внедрением у данного клиента?
какие сотрудники будут реализовывать техническое задание и соответствует ли их квалификация уровню договора?
Следует обратить особое внимание на создание технического задания. От качества технического задания зависит успех и качество выполнения всей автоматизации.
При работе нескольких сотрудников над комплексной автоматизацией предприятия необходим сотрудник, который будет отвечать за весь процесс внедрения, и который будет иметь| полномочия требовать с подчиненных ему сотрудников выполнения| планов работ.
Конфигурация на базе системы программ «1С: Предприятие»
Система программ «1С: Предприятие» (локальная, сетевая, SQL-серверная)
Сетевая операционная система (Windows NT, Novell NetWare)
Разделы технического задания
Основание для разработки.
В данном разделе идентифицируется работа и ее заказчик, акцентируется внимание на организационных и методических материалах положенных в основу работы.
В разделе указываются:
наименование работы, краткое ее содержание, условное обозначение, если оно имеется;
наименование организации заказчика;
перечень документов, на основании которых ведется разработка с указанием полного названия этих документов и данных об их утверждении;
наименование программы 1С и ее условное обозначение, принятой для проведения привязки к объекту;
перечень исходных материалов, использованных при разработке технического задания, в том числе материалы обследования, нормативно-технические документы, рекомендованные для использования, методические, проектные, научно-исследовательские разработки и т.п.; по каждому из приведенных материалов указываются данные об их утверждении, а также - какие именно разделы документов использованы;
место проведения работ по привязке программ 1С.
Назначение разработки.
В разделе указывается функциональное назначение разработки. Программы 1С имеют определенное функциональное назначение. Они ориентированы на реализацию регламентированного состава учетных задач с фиксированными алгоритмами решения. В разделе приводятся наименования задач в составе программ 1С, которые будут переработаны. Здесь же перечисляются задачи, которые будут дополнительно разработаны и включены в состав программ 1С.
Указываются отклонения от программ 1С по содержанию задач.
Поясняется, каким образом будут использоваться результаты решения переработанных задач.
РегистрацияИзменений
Включить / выключить режим регистрации изменений объ екта.
Синтаксис:
РегистрацияИзменений ([ВклВыкл])
Англоязычный синоним:
ЕпаЫеР.ед1з1:егирс1а1:е
Параметры:
[Вкл/Выкл] Число 1 - если изменения должны регистрироваться, число 0 - если изменения не должны регистрироваться. Если параметр не указан, то режим не изменяется.
Возвращаемое значение:
Функция возвращает установленный до ее вызова режим. Число 1 - если режим регистрации для данного объекта установлен и число О,если нет.
Описание:
Метод РегистрацияИзменений доступен только у объектов типа «Справочник» и -«Документ» созданных функцией «СоздатьОбъект». Он применяется для установки режима регистрации изменений, выполняемых данным агрегатным объектом. Первоначально этот режим соответствует установленному для объектов данного вида режиму в метаданных.
Замечание. Особенностью вызова данного метода является то, что он действует с момента своего вызова и до перепозиционирования объекта. То есть, его следует вызывать после того, как объект выбран, и до записи изменений. После следующего позиционирования объекта режим снова будет установлен в соответствии с режимом выбранном в метаданных.
Пример:
//Специальное перепроведение
//без регистрации изменений Процедура СпециальиоеПерепроведение()
Док = Создать0бъект(«Документ.Накладная»);
Док.Вы5ратьДокументы('01.01.98','31.12.98');
Пока Док.ПолучитьДокумент() -•1 Цикл
Док. РегистрацияИзменений (0) ;
Док.провести() ;
КонецЦикла;
КонецПроцедуры
Ручная выгрузка и загрузка на центральной ИБ
Общий вид диалога «Управление распределенными данными» для центральной ИБ приводится ниже:
Для осуществления выгрузки измененных данных на периферийную ИБ в списке «Периферийные информационные базы» выберите ИБ, для которой готовится выгрузка (2-я периферийная ИБ на рисунке), нажмите кнопку диалога «Выгрузить данные», в открывшемся окне введите спецификацию имени файла переноса данных и нажмите кнопку «ОК». В случае, если файл с таким именем уже существует, система выдаст предупреждение и запросит подтверждения.
При вводе имени файла можно указать пароль ZIP, защищающий файл переноса от несанкционированного использования.
Для осуществления загрузки измененных данных с периферийной ИБ нажмите кнопку «Загрузить данные» диалога, в открывшемся окне введите спецификацию имени файла переноса данных и нажмите кнопку «ОК». Если при выгрузке вводился пароль ZIP, то его необходимо указать при вводе файла.
Производить выборку периферийной ИБ при загрузке необязательно - система определит сама, откуда пришла выгрузка. В случае, если загрузку произвести невозможно (например, файл не является файлом переноса данных, сформированным Конфигуратором периферийной ИБ), система выдаст предупреждение и загрузки.
Ручная выгрузка и загрузка на периферийной ИБ
Общий вид диалога «Управление распределенными данными» для периферийной ИБ приводится ниже:
Системные функции
Для отражения в конфигурации особенностей работы в распределенной информационной базе предназначены следующие системные фунвдии:
Соблюдение расписания
При непосредственной работе с клиентом, сотрудник всегда договаривается с клиентом о времени звонка или своего визита. Не допускается опоздание без уважительной причины или пропуск встречи (это просто ужасно).
Если Вы видите, что опаздываете на встречу, то практически всегда можно перезвонить клиенту и извиниться за свое опоздание. Всегда спросите клиента, удобно ли ему перенести встречу на время Вашего опоздания. Если неудобно, то попытайтесь назначить встречу на другое время. На перенесенную встречу опаздывать (а тем более пропускать ее) нельзя ни в коем случае!
В случае если Вы не можете встретиться с клиентом в оговоренное время, то обязательно позвоните ему, извинитесь, если возможно, то назовите причину, по которой Вы не можете выполнить Вашу договоренность и постарайтесь перенести встречу на другое время (причем в назначении времени приоритет остается за клиентом, как за пострадавшей стороной).
Из всего вышеперечисленного следует, что у сотрудника, работающего с клиентом всегда должен быть контактный телефон ответственного сотрудника клиента. Крайне желательно, чтобы Ваш сотрудник знал не только офисный номер телефона, но и мобильный (пейджер) номер клиента для экстренной связи.
Если у сотрудника есть пейджер, то клиент всегда должен знать номер пейджера сотрудника (сотрудников), которые у него работают.
Сопровождение
В последнее время все большее и большее количество клиентов требуют, чтобы фирма-франчайзи сопровождала своих клиентов после окончания работ.
Сопровождение бывает двух видов: по договору и без договора. Кроме того, на фирме-франчайзи обязательно должна быть линия консультации, которой бесплатно могут пользоваться клиенты фирмы. Далее мы подробнее рассмотрим каждый вид сопровождения.
Более подробно документацию по сопровождению можно найти в главе 3.2.5. книги [I].
Сортировка данных в таблице
Сортировка данных в таблице
Операция сортировки данных используется всегда для удобства нахождения нужной информации. Когда на экране (или на бумаге) отображается таблица, гораздо легче найти нужную строку, если эти строки упорядочены. Вы привыкли к тому, что табличные данные упорядочены по алфавиту, по дате, по увеличению или уменьшению значений в столбцах, содержащих числа. Но в разных ситуациях мы хотели бы сортировать строки по разным признакам (столбцам таблицы). В идеале это должно выполняться легким движением руки. Именно так и позволяет делать Access. По умолчанию, когда таблица открывается в режиме Таблицы, она упорядочивается по значению ключевого поля. Если ключевое поле для таблицы не определено, записи выводятся в порядке их ввода в таблицу. Если нужно отсортировать записи по значению другого поля, достаточно установить курсор на любую строку соответствующего столбца и нажать одну из кнопок на панели инструментов: Сортировка по возрастанию (Sort Ascending) или Сортировка по убыванию (Sort Descending).
Другой способ выполнения этой операции: щелкнуть правой кнопкой мыши по любой строке нужного столбца и выбрать из контекстного меню (рис. 2.55) соответствующую команду.
Таким образом можно упорядочить записи по любому столбцу таблицы. Ограничения существуют только на тип данных, которые можно упорядочивать — нельзя сортировать значения полей типа MEMO, гиперссылки или объекты OLE.
Чтобы правильно применять сортировку, нужно знать несколько простых правил.
При сортировке в возрастающем порядке записи, содержащие пустые поля (с пустыми значениями), указываются в списке первыми.
Числа, находящиеся в текстовых полях, сортируются как строки символов, а не как числовые значения. Если нужно отсортировать их в числовом порядке, все текстовые строки должны содержать одинаковое количество символов. Если строка содержит меньшее количество символов, то сначала нужно вставить незначащие нули.
При сохранении таблицы сохраняется и порядок ее сортировки.
Сортировка, поиск и фильтрация данных
Сортировка, поиск и фильтрация данных
Данные, которые хранятся в таблицах базы данных, могут быть эффективно использованы только при условии если существуют простые и доступные средства поиска нужной информации. Таблицы могут содержать огромное число записей, и хорошая СУБД должна обеспечить возможность быстро и легко найти и отобрать среди них нужные. Access 2002 является в этом отношении примером того, как можно при выполнении этих операций обеспечить максимальное удобство для пользователей и в то же время эффективность обработки больших объемов данных.
Состав технического задания
Основание для разработки.
Назначение разработки.
Методологические основы решения задач.
Функциональные спецификации и описание алгоритмов.
Условия эксплуатации.
Порядок контроля работоспособности программ и их приемка.
Этапы разработки.
Создание образа периферийной ИБ
Для создания образа новой периферийной ИБ нажмите кнопку «Новая периф. ИБ» в диалоге «Управление распределенными данными» Конфигуратора. Заметим, что эта операция недоступна, пока не проинициализирована центральная ИБ.
В появившемся диалоге введите код и описание новой периферийной информационной базы:
Поменять код периферийной информационной базы в дальнейшем будет невозможно, поэтому, если планируется каким-либо образом использовать код ИБ (например, для определения типа ИБ при работе 1С:Предприятия: первый символ «С» - склад, «М» - магазин и т.д.) - заранее продумайте систему кодов информационных баз распределенной конфигурации.
В диалоге инициализации периферийной информационной базы можно включить флажок «Только получатель». Если этот признак установлен, то обмен с данной информационной базой будет заключаться только в передаче в нее изменений из центральной ИБ. Изменения, выполняемые в этой периферийной ИБ, не будут передаваться в центральную информационную базу. При этом сам файл переноса выгружаться будет, и должен загружаться в центральной ИБ. Но он будет содержать только подтверждения получения изменений периферийной ИБ. Признак «Только получатель» также как и код ИБ I может быть изменен после инициализации периферийной информационной базы.
Повторите эту процедуру для всех периферийных ИБ, которые Вы планируете создать в данный момент. Изменить структуру информационных баз данных будет возможно позднее, в том числе и после
запуска распределенной ИБ в эксплуатацию. Подробнее об этом смотрите в разделе «Управление структурой распределенной информационной базы».
Нажмите на кнопку «Пар. автообмена» и в открывшемся диалоге задайте каталоги, имена файлов и режимы автообмена для созданных периферийных ИБ. Подробнее о работе с диалогом «Настройка параметров автообмена» и режимах автообмена смотрите в разделе «Автообмен. Настройка и использование».
Для первичной выгрузки данных выберите конкретную ИБ из списка периферийных информационных баз. нажмите кнопку «Выгрузить данные» и введите имя файла (расширение можно не указывать, по умолчанию -ZIP, в которую следует произвести выгрузку:
Установив опцию выгрузки данных «Выгружать сведения о пользователях», в первичную выгрузку можно включить информацию о пользователях центральной ИБ, определенных на момент первичной выгрузки. В дальнейшем информация о пользователях в файл переноса данных включаться не будет: список пользователей ведется на каждой ИБ индивидуально.В диалоге выбора имени файла можно также ввести пароль ZIP. Пароль позволяет защитить файл переноса от несанкционированного использования. В качестве пароля может выступать любая последовательность символов.
Способ физической передачи файла переноса данных между центральной и периферийной ИБ системой жестко не определен и зависит от возможностей пользователя. Поэтому устройством для вывода может быть и стандартная дискета, и жесткий диск (если, например, осуществлять передачу планируется посредством электронной почты). Необходимо только, чтобы для обоих ИБ способ передачи файла был физически реализуем.
Файл первичной выгрузки находится на особом положении среди файлов переноса данных. Он формируется только центральной ИБ, только один раз, не должен быть утерян и обязательно должен быть введен первым при инициализации периферийной ИБ. Система помечает ИБ в списке значками яряч 1-я периферийная ИБ базы, для которых файл первичной выгрузки был создан, аЯ^2 2-я периферийная иб - для которых первичная выгрузка не проводилась.
Создание программных модулей
Создание и использование индексов
Создание и использование индексов
С целью ускорения поиска и сортировки данных в любой СУБД используются индексы. Индекс является средством, которое обеспечивает быстрый доступ киданным в таблице на основе значений одного или нескольких столбцов. Индекс представляет собой упорядоченный список значений и ссылок на те записи, в которых хранятся эти значения. Чтобы найти нужные записи, СУБД сначала ищет требуемое значение в индексе, а затем по ссылкам быстро отбирает соответствующие записи. Индексы бывают двух типов: простые и составные. Простые индексы представляют собой индексы, созданные по одному столбцу. Индекс, построенный по нескольким столбцам, называется составным. Примером составного индекса может быть индекс, построенный по столбцам "Фамилия" и "Имя".
Однако применение индексов приносит не только преимущества, но и недостатки. Главным среди них является тот, что при добавлении и удалении записей или при обновлении значений в индексном столбце требуется обновлять индекс, что при большом количестве индексов в таблице может замедлять работу. Поэтому индексы обычно рекомендуется создавать только для тех столбцов таблицы, по которым наиболее часто выполняется поиск записей. Во многих СУБД (например, FoxPro) индексы хранятся в отдельных файлах и являются предметом заботы разработчиков, т. к. при нарушении индекса поиск данных выполняется некорректно. В Microsoft Access индексы хранятся в том же файле базы данных, что и таблицы и другие объекты Access. Индексировать можно любые поля, кроме МЕМО-полей, полей типа Гиперссылка и объектов OLE.
Чтобы создать простой индекс, необходимо:
-
Открыть таблицу в режиме Конструктора.
Выбрать поле, для которого требуется создать индекс.
Открыть вкладку Общие (General) и выбрать для свойства Индексированное поле (Indexed) значение Да (Допускаются совпадения) (Yes (Duplicates OK)) или Да (Совпадения не допускаются) (Yes (No duplicates)) (рис. 2.24).
Создание таблиц
В Access используются три способа создания таблиц: путем ввода данных (by entering data), с помощью Конструктора таблиц (in Design view) и с помощью Мастера создания таблиц (by using wizard). Для каждого из этих способов существует специальный ярлык новых объектов в списке таблиц (рис. 2.3). Если вы создали новый файл базы данных, то, кроме этих ярлыков, в списке таблиц больше ничего нет.
Создание таблиц с помощью Мастера таблиц
Создание таблиц с помощью Мастера таблиц
Для этого необходимо:
-
Дважды щелкнуть левой кнопкой мыши на ярлыке
Создание таблицы с помощью мастера
(Create table by using wizard).
В диалоговом окне Создание таблиц (Table Wizard) (рис. 2.7) выбрать назначение таблицы: Деловые (Business) (для иных целей можно выбрать и Личные (Personal)).
В поле Образцы таблиц (Sample Tables) выбрать подходящую таблицу — Список рассылки (MailingList).
Переместить нужные поля из списка Образцы полей (Sample Fields) в список Поля новой таблицы (Fields in my new table). Для этого следует воспользоваться кнопками со стрелками: > — переместить одно поле, » — переместить все поля.
Создание таблицы путем ввода данных
Создание таблицы путем ввода данных
Если вы затрудняетесь сразу определить структуру таблицы, Microsoft Access позволяет создать таблицу путем ввода данных в окно с традиционной табличной формой (рис. 2.5).
Создание таблицы с помощью Конструктора таблиц
Создание таблицы с помощью Конструктора таблиц
Теперь мы познакомимся с режимом Конструктора. В режиме Конструктора таблицы создаются путем задания имен полей, их типов и свойств. Чтобы создать таблицу в режиме Конструктора, необходимо:
-
Дважды щелкнуть левой кнопкой мыши на ярлыке
Создание таблицы с помощью конструктора
(Create table in Design View) или нажать на кнопку
Создать
(New) в верхней части окна базы данных, выбрать из списка в окне
Новая таблица
(New Table) элемент
Конструктор
(Design View) и нажать кнопку ОК. В том и в другом случае откроется пустое окно Конструктора таблиц (рис. 2.14).
Способы маркетинговой борьбы с данным конкурентом
Рекомендуется обратить внимание руководителя предприятия на описание системы ГАЛАКТИКА (стр.5) и задуматься, каким образом, по каким данным, каким критериям и по каким алгоритмам проводится анализ, планирование, как учитывается реализация плана и как осуществляется его контроль (рис1 Схема управления предприятием). Необходимо объяснить, что анализировать при оперативном управлении на самом деле нечего. Есть просто конкретный алгоритм расчета необходимых к ПОКУПКЕ (не к производству) ресурсов и дат этих покупок в соответствии с имеющимся и будущим спросом, который и реализован в Oracle Application.
Необходимо объяснить руководству, что основные потери предприятие несет при не обоснованных закупках, и отследить вручную этот процесс (на крупных предприятиях) невозможно. ГАЛАКТИКА и не пытается исправить это положение. Oracle Application предлагает эффективные способы решения этих проблем.
Руководству предприятия необходимо продемонстрировать обеспечение контроля бюджета при вводе оперативных документов.
Если руководитель уверовал в то, что система очень модульная и собирается из кубиков, необходимо показать, что это действительно так, потому что модули просто не имеют связей между собой.
Если все это не убеждает, то выбором системы занимается Главный бухгалтер или финансист, который либо не знает вопросов управления предприятия в целом, либо его эти вопросы не интересуют.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Средства встроенного языка, ориентированные на работу с распределенной ИБ
Системные функции
ТекущаяИБКод
ТекущаяИБНаименование
ЦентральнаяИБКод
ТекущаяИБЦентральная
ИБСозданияОбъекта
ТекущаяИБТолькоПолучатель
Методы агрегатных объектов
РегистрацияИзменений
Структура Руководства
Настоящее Руководство состоит из разделов, каждый из которых описывает характерные особенности работы с компонентой «Управление распределенными ИБ».
В главе 1 рассматривается порядок установки компоненты.
Глава 2 дается представление о принципах работы компоненты и алгоритмах разрешения спорных ситуаций, возникающих в процессе функционирования распределенной ИБ.
Глава 3 описывает процесс создания распределенной информационной базы.
В главе 4 дается описание действий пользователя, необходимых для осуществления переноса данных между информационными базами распределенной системы.
Глава 5 описывает различные режимы миграции данных в распределенной системе и методику установки свойств миграции «ведущих» объектов.
В главе б дается описание функций встроенного языка системы 1С:Предприятие, предназначенных для работы с распределенной конфигурацией.
В главе 7 описываются особенности конфигурирования 1С:Предприятия для работы с распределенной информационной базой.
Свойства полей таблицы
Свойства полей таблицы
Для большинства типов данных характерно свойство Подпись (Caption). С помощью этого свойства можно задать названия полей таблицы, которые выводятся в различных режимах (в надписях, присоединенных к элементам управления формы, в заголовке столбца в режиме Таблицы; в строке заголовка в режиме Формы; в заголовке отчета, выводящемся в режиме Предварительного просмотра; текст, который выводится в элементе управления). Поле может содержать до 2048 символов.
Кроме того, для большинства типов данных существует свойство Обязательное поле (Required), которое определяет необходимость ввода данных в это поле..
Совет
Настоятельно рекомендуем устанавливать значение этого свойства равным Да (Yes) для тех полей таблицы, которые не должны быть пустыми. Это обеспечивает автоматический контроль ввода данных в такие поля, т. е. ни при каких обстоятельствах пользователь не сможет создать запись, в которой данное поле останется пустым.
С помощью свойства Маска ввода (Input Mask) указывается маска, позволяющая автоматизировать проверку ввода символов в поле. Она применяется к таким полям, как номер телефона, дата и т. д. Задавать маску ввода можно вручную или с помощью Мастера. (К маскам ввода мы еще вернемся в разд. "Форматы отображения данных" этой главы.)
Свойство Индексированное поле (Indexed) определяет, является ли данное поле индексированным, и если является, то в каком режиме. Существуют два режима индексирования: Совпадения допускаются (Duplicates OK) и Совпадения не допускаются (No duplicates). В первом случае поле может содержать повторяющиеся значения, во втором — нет.
Для большинства типов полей определено свойство Значение по умолчанию (Defau.lt Value). В этом свойстве указывается значение, автоматически добавляемое в поле для каждой новой записи, если это значение не введено пользователем.
Внимание
Обратите внимание, что значение по умолчанию присваивается только при вводе новой записи. Если вы установите это значение для таблицы, в которой уже существуют записи, то в старых записях значение этого поля не изменится.
Условие на значение (Validation Rule) — свойство определяет условие (ограничение), накладываемое на вводимые в это поле данные. При несоответствии вводимых данных указанному условию выдается сообщение об ошибке.
Сообщение об ошибке (Validation Text) — свойство определяет то сообщение, которое будет выдаваться пользователю, если при вводе данных не соблюдается условие, указанное в свойстве Условие на значение (Validation Rule).[ Если это свойство не указано, будет выдано стандартное сообщение об ошибке. ]
В табл. 2.2—2.4 приводятся свойства, специфичные для полей определенного типа.
Связывание таблиц на схеме данных
Связывание таблиц на схеме данных
Для того чтобы было удобно просматривать, создавать, удалять и модифицировать связи между таблицами, в Microsoft Access используется схема данных (Relationships) (рис. 2.27).
Панель инструментов Таблица в режиме Таблицы
Таблица 2.1. Панель инструментов Таблица в режиме Таблицы
|
Кнопка |
Описание |
Команда меню |
||
|
Вид (View) |
Отображение таблицы в различных ре- |
Вид, Режим таблицы |
||
|
|
жимах. Чтобы изменить режим отобра- |
(View, Datasheet View) |
||
|
|
жения таблицы, нажмите стрелку справа |
|
||
|
|
от кнопки и в появившемся списке вы- |
|
||
|
|
делите нужный элемент. Если просто |
|
||
|
|
нажать эту кнопку, таблица будет ото- |
|
||
|
|
бражена в режиме Таблицы |
|
||
|
Сохранить (Save) |
Сохранение активной таблицы |
Файл, Сохранить |
||
|
|
|
(File, Save) |
||
|
Найти (Search) |
Поиск документов по содержанию |
Файл, Найти (File, |
||
|
|
|
Search) |
||
|
Печать (Print) |
Печать таблицы без открытия диалогово- |
Нет |
||
|
|
го окна Печать |
|
||
|
Предварительный |
Предварительный просмотр размещения |
Файл, Предвари- |
||
|
просмотр |
таблицы на листе перед печатью |
тельный просмотр |
||
|
(Print Preview) |
|
(File, Print Preview) |
||
|
Орфография |
Проверка орфографии в текстовых по- |
Сервис, |
||
|
(Spelling) |
лях таблицы |
Орфография |
||
|
|
|
(Tools, Spelling) |
||
|
Вырезать (Cut) |
Удаление выделенных объектов из таб- |
Правка, Вырезать |
||
|
|
лицы в буфер обмена Windows |
(Edit, Cut) |
||
|
Копировать (Сору) |
Копирование выделенных объектов в |
Правка, Копировать |
||
|
|
буфер обмена |
(Edit, Copy) |
||
|
Вставить (Paste) |
Вставка содержимого из буфера обмена |
Правка, Вставить |
||
|
|
|
(Edit, Paste) |
||
|
Формат |
Копирование параметров форматирова- |
Нет |
||
|
по образцу |
ния из одного выделенного объекта в |
|
||
|
(Format Painter) |
другой такого же типа |
|
||
|
Кнопка
|
Описание
|
Команда меню
|
||
|
Отменить (Undo) |
Отмена последних действий |
Правка, Отменить
(Edit, Undo) |
||
|
Добавить гиперссылку (Insert Hyperlink) |
Вставка поля типа "гиперссылка" |
Вставка, Гиперссылка (Insert, Hyperlink Column) |
||
|
Сортировка по возрастанию (Sort Ascending) |
Сортировка записей по возрастанию значений в активном поле |
Записи, Сортировка, Сортировка по возрастанию (Records, Sort, Sort Ascending |
||
|
Сортировка по убыванию (Sort Descending) |
Сортировка записей по убыванию значений в активном поле |
Записи, Сортировка, Сортировка по убыванию (Records, Sort, Sort Descending |
||
|
Фильтр по выделенному (Filter by selection) |
Отбор записей, соответствующих выделенному фрагменту |
Записи, Фильтр, Фильтр по выделенному (Records, Filter, Filter by selection) |
||
|
Изменить фильтр
(Filter by form) |
Отображение диалогового окна для ввода критериев отбора записей |
Записи, Фильтр, Изменить фильтр
(Records, Filter, Filter by form) |
||
|
Применение фильтра (Apply filter) |
Отображение отфильтрованных записей |
Записи, Применить фильтр (Records, Apply filter) |
||
|
Найти (Find) |
Поиск записи по заданным критериям поиска |
Правка, Найти
(Edit, Find) |
||
|
Новая запись (New Record) |
Добавление новой записи в таблицу |
Вставка, Новая запись (Insert, New Record) |
||
|
Удалить запись
(Delete Record) |
Удаление текущей записи из таблицы |
Правка, Удалить запись (Edit, Delete Record) |
||
|
Окно базы данных
(Database Window) |
Отображение окна базы данных |
Окно, 1 (Window, 1) |
||
|
Новый объект
(New Object) |
Создание нового объекта базы данных. Чтобы выбрать тип создаваемого объекта, нажмите стрелку справа от кнопки |
Нет |
||
|
Справка по Microsoft Access
(Microsoft Access Help) |
Вызов помощника и получение справки по Access 2002 |
Справка, Справка по Microsoft Access
(Help, Microsoft Access Help) |
||
выделить таблицу в списке таблиц в окне базы данных и нажать кнопку Конструктор (Design) в верхней части окна базы данных;
щелкнуть правой кнопкой мыши на имени таблицы и из контекстного меню выбрать команду Конструктор (Design).
После выполнения указанных действий на экране появится окно таблицы в режиме Конструктора, а также панель инструментов Конструктор таблиц (Table Design) (рис. 2.2).
Дополнительные свойства текстового поля и поля Memo
Таблица 2.2. Дополнительные свойства текстового поля и поля Memo
|
Наименование свойства - |
Описание |
||
|
Пустые строки (Allow Zero Length) |
Свойство определяет, допустимо ли вводить в данное поле пустые строки
|
||
|
Сжатие Юникод (Unicode Compression) |
Свойство определяет, выполняется ли сжатие данных при сохранении для полей текстового типа (при кодировке UNICODE удаляются все первые байты символов, если они равны 0) |
||
| Режим IME (IME Mode) |
Input Method Editor — программа, позволяющая распознавать вводимые с помощью специальных кодов символы азиатских алфавитов: китайского, корейского и японского. Свойство позволяет указать режим преобразования, которое выполняется при получении полем фокуса |
||
|
Режим предложений
IME (IME Sentence Mode) |
Определяет режим предложений IME, которые применяются при получении полем фокуса |
Дополнительные свойства полей числового и денежного типа
Таблица 2.3. Дополнительные свойства полей числового и денежного типа
|
Наименование свойства |
Описание |
||
|
Число десятичных знаков (Decimal Places) |
Свойство определяет число десятичных знаков справа от десятичного разделителя. Значение свойства можно выбрать из раскрывающегося списка. Чтобы число знаков определялось автоматически, необходимо установить значение Авто (Auto) |
||
Дополнительные свойства полей типа Счетчик
Таблица 2.4. Дополнительные свойства полей типа Счетчик
|
Наименование свойства |
Описание |
||
|
Размер поля (FieldSize) |
Это свойство определяет размер и тип чисел, вводимых в поле. В данном случае из раскрывающегося списка можно выбрать только два значения: Длинное целое (Long Integer) и Код репликации (Replication ID). Код репликации (Replication ID) является глобальным уникальным 16-байтовым значением, которое используется для идентификации записи в таблице (см. гл. 18). В случае, когда этому свойству присвоено значение Код репликации (Replication ID), для данного поля доступной становится только часть свойств |
||
|
Новые значения
(New Values) |
Указывается способ формирования следующего значения счетчика. Из списка можно выбрать два варианта: Последовательные (Increment) и Случайные (Random) |
Свойства подстановки для поля со списком
Таблица 2.5. Свойства подстановки для поля со списком
|
Наименование свойства |
Описание |
||
|
Тип источника строк
(Row Source Type) *
|
Свойство определяет тип источника строк для списка или поля со списком. Может принимать три значения: Таблица или запрос (Table/Query), Список значений (Value List) и Список полей (Field List) |
||
|
Источник строк (Row Source) * |
Свойство определяет источник данных элемента управления. При выборе типа источника строк Список значений (Value List) оно представляет собой список элементов, разделяемых точкой с запятой (;), в противном случае — имя таблицы или запроса или инструкцию языка SQL | ||
| Присоединенный столбец (Bound Column) * | Свойство определяет номер столбца списка или поля со списком, содержащего значение элемента управления. Если это свойство имеет значение 0, то в поле передается номер строки списка, если 1 и больше, то в поле передаются данные из соответствующего столбца списка. Значение этого свойства не может превышать значение свойства Число столбцов (Column Count.) |
|
Наименование свойства
|
Описание
|
||
|
Число столбцов
(Column Count) * |
Свойство определяет число столбцов, выводимых в списке или в поле со списком. Если в качестве источника строк используется Таблица или запрос (Table/Query), то в списке будут выводиться столбцы таблицы, начиная с первого и заканчивая тем, который указан в значении данного свойства. Если в качестве источника строк используется список значений, то в списке будет выводиться указанное число столбцов, а данные в них будут располагаться построчно в последовательности, указанной в свойстве Источник строк (Row Source) |
||
|
Заглавия столбцов
(Column Heads) * |
Свойство определяет, используются ли первые элементы списка или поля со списком как заголовки столбцов |
||
|
Ширина столбцов
(Column Widths) * |
Свойство определяет ширину столбцов списка или поля со списком. При использовании нескольких столбцов значения разделяются точкой с запятой (;). Задав нулевое значение, можно скрыть столбец |
||
|
Число строк списка
(List Rows) |
Свойство определяет максимальное число строк для поля со списком. Если количество элементов списка превысит указанное число строк, в списке появится линейка прокрутки |
||
|
Ширина списка (List Width) |
Свойство определяет ширину раскрывающегося списка для поля со списком |
||
|
Ограничиться списком (Limit to List) |
Свойство определяет, могут ли вводиться в поле со списком значения, не являющиеся элементами списка. |
||
Встроенные числовые форматы для числовых и денежных типов данных
Таблица 2.6. Встроенные числовые форматы для числовых и денежных типов данных
|
Значение |
Описание |
||
|
Основной (General Number) |
Используется в качестве значения по умолчанию. Числа отображаются так, как они были введены. Пример: 12345,67 |
||
|
Денежный (Currency) |
Число выводится с разделителями разрядов и символом национальной валюты, введенным в локальных установках. Пример: 3 457 р |
||
|
Евро (Euro) |
Частный случай предыдущего формата со знаком валюты евро. Пример: 3 457 € |
||
|
Фиксированный
(Fixed) |
Числа выводятся без разделителей групп разрядов. Пример: 3456,79 |
||
|
С разделителями разрядов (Standard) |
Числа выводятся с разделителями групп разрядов. Пример: 3 456,79 |
||
|
Процентный (Percent) |
Значение умножается на 100; добавляется символ процента (%). Пример: 98,00% |
||
|
Экспоненциальный
(Scientific) |
Числа выводятся в экспоненциальном виде. Пример: 3.46Е+03 |
||
Числовые форматы также можно определять самостоятельно с помощью специальных символов. Они могут включать в себя от одного до четырех разделов, отделенных друг от друга точкой с запятой (;). В первом разделе описывается формат положительных чисел, во втором — формат отрицательных чисел, в третьем — формат нулевых значений, в четвертом — формат пустых (Null) значений.
Символы форматирования для числовых типов данных
Таблица 2.7. Символы форматирования для числовых типов данных
|
Символ
|
Описание
|
||
|
. (точка) |
Десятичный разделитель. Символ десятичного разделителя выбирается в окне Язык и стандарты панели управления Windows |
||
| , (запятая) | Разделитель групп разрядов Прототип разряда. | ||
| 0 | Выводится цифра или 0 Прототип разряда. | ||
|
# |
Выводится цифра или ничего не выводится | ||
| $ |
Выводится символ доллара ($) |
|
Символ |
Описание |
||
|
% |
Процентный формат. Число умножается на 100 и к нему добавляется символ процентов |
||
|
Е- или е- |
Экспоненциальная нотация (перед отрицательными показателями степени изображается знак минус, а перед положительными ничего). Этот символ используется только вместе с другими символами (например, 0 , 00Е-00) |
||
|
Е+ или е+ |
Экспоненциальная нотация (перед отрицательными показателями степени изображается знак минус, а перед положительными знак плюс). Этот символ используется только вместе с другими символами (например,
0,00Е+00) |
||
Для добавления в специальный формат запятой или другого символа разделителя следует ввести этот символ в кавычках, например, формат " # " ## задает последовательности вида #1, #35, #, #99.
Встроенные форматы для полей типа Дата/Время
Таблица 2.8. Встроенные форматы для полей типа Дата/Время
|
Значение
|
Описание
|
||
|
Полный формат даты (General Date) |
Значение используется по умолчанию. Если значение содержит только дату, то время не отображается; а если — время, то не отображается дата, Данный формат является комбинацией двух форматов: Краткий формат даты и Длинный формат времени. Примеры: 01.01.99 12:08:02 и 23.02.99 00:00:00 |
||
|
Длинный формат даты (Long Date) |
Совпадает с настройкой, задающейся в окне Язык и стандарты панели управления Windows. Пример: 12 января 1999 г. |
||
|
Средний формат даты (Medium Date) |
В российской практике используется редко. Пример: 03-янв-99 |
||
|
Краткий формат даты (Short Date) |
Значения краткого формата даты предполагают, что даты из диапазона 01 .01 .00 и 31 .12.29 обозначают годы от 2000 до 2029, тогда как даты из промежутка 01.01.30 и 31.12.99 обозначают годы от 1930 до 1999. Пример: 1 1 .06.95 |
||
|
Длинный формат времени (Long Time) |
Пример: 20:58:10 |
||
|
Средний формат времени (Medium Time) |
В российской практике обычно не используется. Пример: 5:34 РМ |
||
|
Краткий формат времени (Short Time) |
Пример: 17:34 |
||
Символы форматирования для типа данных Дата/Время
Таблица 2.9. Символы форматирования для типа данных Дата/Время
|
Символ
|
Описание
|
||
|
: (двоеточие) |
Разделитель компонентов времени. Символ разделителя выбирается в окне Язык и стандарты панели управления Windows |
||
|
/ |
Разделитель компонентов даты |
||
|
с |
Задает встроенный Полный формат даты |
||
|
d |
Номер дня месяца, состоящий из 1 или 2 цифр (1-31) |
||
|
dd |
Номер дня месяца, состоящий из 2 цифр (01—31) |
||
|
ddd |
Сокращенное название дня недели (Пн-Вс) |
||
|
dddd |
Полное название дня недели (понедельник— воскресенье) |
||
|
ddddd |
Задает встроенный Краткий формат даты |
||
|
dddddd |
Задает встроенный Длинный формат даты |
||
|
w |
Номер дня недели (1-7) |
||
|
ww |
Номер недели в году (1-53) |
||
|
Itl |
Номер месяца, состоящий из 1 или 2 цифр (1-12) |
||
|
mm |
Номер месяца, состоящий из 2 цифр (01-12) |
||
|
mmm |
Первые три буквы названия месяца (янв— дек) |
||
|
mmmm |
Полное название месяца (Январь— Декабрь) |
||
|
q |
Номер квартала в году (1-4) |
||
|
у |
Номер дня в году (1-366) |
||
|
УУ |
Последние две цифры номера года (01-99) |
||
|
УУУУ |
Полный номер года (0100-9999) |
||
|
h |
Число часов, состоящее из 1 или 2 цифр (0-23) |
||
|
hh |
Число часов, состоящее из 2 цифр (00-23) |
||
|
n |
Число минут, состоящее из 1 или 2 цифр (0-59) |
||
|
nn |
Число минут, состоящее из 2 цифр (00—59) |
||
|
s |
Число секунд, состоящее из 1 или 2 цифр (0-59) |
||
|
ss |
Число секунд, состоящее из 2 цифр (00-59) |
||
|
ttttt |
Задает встроенный Длинный формат времени |
||
|
AM/PM |
12-часовой формат времени с добавлением прописных букв "AM" или "РМ" |
||
|
am/pm |
12-часовой формат времени с добавлением строчных букв "am" или "рm" |
||
|
A/P |
12-часовой формат времени с добавлением прописных букв "А" или "Р" |
||
|
Символ |
Описание |
||
|
а/р |
12-часовой формат времени с добавлением строчных букв "а" или "р" |
||
| АМРМ | 12-часовой формат времени; используется индикатор "утро/день", выбранный в окне Язык и стандарты панели управления Windows |
Символы форматирования для текстовых и МЕМО-полей
Таблица 2.10. Символы форматирования для текстовых и МЕМО-полей
|
Символ |
Описание |
||
|
@
|
Обязательный текстовый символ или пробел |
||
| & | Необязательный текстовый символ | ||
| < | Преобразует все символы в строчные | ||
| > |
Преобразует все символы в прописные |
Специальный логический формат может содержать от одного до трех разделов, разделяемых точкой с запятой (;). Первый раздел не влияет на формат логических значений, но символ точки с запятой указать необходимо. Во втором разделе задается строковое выражение, определяющее значение Истина (True), Да (Yes) или Вкл (On), а в третьем — строковое выражение, определяющее значение Ложь (False), Нет (No) или Выкл (Off).
Не разрешается смешивать в одном формате специальные символы, предназначенные для определения числовых форматов, форматов даты/времени и текстовых форматов. Но существует ряд символов форматирования, которые используются для любых типов данных. Эти символы представлены в табл. 2.11.
Символы форматирования для всех типов данных
Таблица. 2.11. Символы форматирования для всех типов данных
|
Символ |
Описание |
||
|
(Пробел ) |
Выводит пробел как символьную константу, т. е. этот пробел выводится всегда |
||
| ! | Определяет выравнивание символов по левому краю | ||
| "ABC" | Символы, заключенные в кавычки, считаются символьными константами | ||
| * | Позволяет заполнить доступное пустое пространство следующим символом | ||
| \ |
Выводит следующий символ как символьную константу |
||
| [цвет] | Задает цвет, название которого указано в скобках. Допустимые имена цветов: (Черный) (Black), (Синий) (Blue), (Зеленый) (Green), (Бирюзовый) (Cyan), (Красный) (Red), (Лиловый) (Magenta), (Желтый) (Yellow), (Белый) (White) |
Символы для создания масок ввода
Таблица 2.12. Символы для создания масок ввода
|
Символ маски |
Описание | ||
|
0 |
В данную позицию должна быть введена цифра. Знаки плюс (+) и минус (-) не допускаются |
||
|
9 |
В данную позицию должна быть введена цифра или пробел. Знаки плюс (+) и минус (-) не допускаются |
||
|
Символ маски
|
Описание
|
||
|
# |
В данную позицию должна быть введена цифра, пробел, знаки плюс (+) или минус (-) |
||
|
;
L |
В данную позицию должна быть введена буква |
||
|
? |
В данную позицию может быть введена буква или пробел |
||
|
А |
В данную позицию должна быть введена буква или цифра |
||
|
а |
В данную позицию должна быть введена буква, цифра или пробел |
||
|
& |
В данную позицию должен быть введен произвольный символ или пробел |
||
|
С |
В данную позицию может быть введен произвольный символ или пробел. Если пользователь ничего не введет, Access не занесет в эту позицию никаких данных |
||
|
. |
Десятичный разделитель (зависит от региональных установок в окне Язык и стандарты Панели управления Windows) |
||
|
, |
Разделитель групп разрядов (зависит от региональных установок в окне Язык и стандарты Панели управления Windows) |
||
|
: - / |
Разделители в значениях даты и времени (зависят от региональных установок в окне Язык и стандарты Панели управления Windows) |
||
|
< |
Преобразует все символы справа к нижнему регистру |
||
|
> |
Преобразует все символы справа к верхнему регистру |
||
|
! |
Указывает, что маску нужно заполнять справа налево. Этот символ следует использовать в том случае, когда символы в левой части маски являются необязательными. Его можно помещать в любой позиции маски |
||
|
\ |
Указывает, что следующий символ необходимо рассматривать в качестве постоянного символа, даже если он является специальным символом маски. Например, \А будет выводить в маске букву А |
||
|
"литерал" |
Вместо того чтобы многократно использовать символ обратного слэша (\), можно просто заключить любой литерал в двойные кавычки |
||
-
В первом диалоговом окне вы можете выбрать нужную маску из списка (рис. 2.22). Если вы попытаетесь вводить данные в поле
Проба
(Try It), то сможете увидеть, как будут форматироваться вводимые вами символы. Нажмите кнопку
Далее
(Next).
Кнопки перемещения по записям таблицы
Таблица 2.13. Кнопки перемещения по записям таблицы
|
Кнопка |
Описание |
||
|
|< |
Перемещение на первую запись таблицы |
||
|
< |
Перемещение на предыдущую запись таблицы |
||
|
> |
Перемещение на следующую запись таблицы |
||
|
>| |
Перемещение на последнюю запись таблицы |
||
|
>* |
Создание новой записи |
||
Для перемещения по полям записи и между записями в режиме Таблицы можно использовать также сочетания клавиш, показанных в табл. 2.14.
Навигация по таблице с помощью клавиш
Таблица 2.14. Навигация по таблице с помощью клавиш
|
Сочетания клавиш |
Действие |
||
|
<F5> |
Переход в поле номера записи |
||
|
<Tab>, <Enter> или <?> |
Переход к следующему полю |
||
|
<End> |
Переход к последнему полю в текущей записи |
||
|
<Shift> + <Tat> или <<> |
Переход к предыдущему полю |
||
|
<Home> |
Переход к первому полю в текущей записи в режиме перемещения |
||
|
<v> |
Переход к текущему полю в следующей записи |
||
|
<Ctrl>+<v> |
Переход к текущему полю в последней записи |
||
|
<Ctrl>+<END> |
Переход к последнему полю в последней записи |
||
|
<^> |
Переход к текущему полю в предыдущей записи |
||
|
<ctrl>+<^> |
Переход к текущему полю в первой записи |
||
|
<Ctrl>+<Home> |
Переход к первому полю в первой записи |
||
|
<Page Down> |
На один экран вниз |
||
|
<Page Up> |
На один экран вверх |
||
|
<Ctrl>+<Page Down> |
На один экран вправо |
||
|
<Ctrl>+<Page Up> |
На один экран влево |
||
Описание элементов панели инструментов Формат (режим таблицы)
Таблица 2.15. Описание элементов панели инструментов Формат (режим таблицы)
|
Название кнопки или списка
|
Команда меню
|
Описание
|
||
|
Перейти на поле
(Go to Field) |
|
Поле со списком служит для быстрого перехода к нужному полю в текущей записи |
||
|
Шрифт (Font) |
Формат, Шрифт
(Format, Font) |
Поле со списком служит для выбора шрифта, который используется для отображения данных |
||
|
Размер шрифта
(Font Size) |
Формат, Шрифт
(Format, Font) |
Поле со списком, в котором можно выбрать или ввести размер шрифта для данных таблицы |
||
|
Полужирный (Bold) |
Формат, Шрифт
(Format, Font) |
Применение полужирного шрифта |
||
|
Курсив (Italic) |
Формат, Шрифт
(Format, Font) |
Применение курсива |
||
|
Подчеркнутый
(Underline.) |
Формат, Шрифт
(Format, Font) |
Применение шрифта с подчеркиванием |
||
|
Цвет заливки/фона
(Fill/Back Color) |
Формат, Режим таблицы (Format, Datasheet) |
Позволяет изменить цвет фона таблицы. При нажатии стрелки справа от кнопки выводится окно с палитрой цветов, в котором можно выбрать цвет фона |
||
|
Название кнопки или списка
|
Команда меню
|
Описание
|
||
|
Цвет текста
(Font/Fore Color) |
Формат, Шрифт
(Format, Font) |
Позволяет изменить цвет шрифта для данных таблицы с помощью палитры цветов |
||
|
Цвет линии/границы
(Line/Border Color) |
Формат, Режим таблицы (Format, Datasheet) |
Позволяет изменить цвет линий сетки с помощью палитры цветов |
||
|
Сетка (Gridlines) |
Формат, Режим таблицы (Format, Datasheet) |
Позволяет выбирать разные типы сетки таблицы: вывод всех линий, только горизонтальных, только вертикальных и отсутствие линий |
||
|
Оформление
(Special Effect) |
Формат, Режим таблицы (Format, Datasheet) |
Позволяет выбрать вид оформления ячеек таблицы: обычное приподнятое или утопленное |
||
Описание кнопок панели инструментов Предварительный просмотр
Таблица 2.16. Описание кнопок панели инструментов Предварительный просмотр
|
Название кнопки или списка
|
Команда меню
|
Описание
|
||
|
Вид (View) |
Вид, Конструктор Вид, Режим таблицы Вид, Сводная таблица Вид, Сводная диаграмма |
Используется для переключения в режим Таблицы, в режим Конструктора, в режим Сводной таблицы в режим Сводной диаграммы |
||
|
Печать (Print) |
Файл, Печать |
Применяется для печати таблицы |
||
|
Масштаб (Zoom) |
Вид, Масштаб |
Позволяет изменять масштаб отображения страницы |
||
|
Одна страница
(One Page) |
Вид, Число страниц |
Позволяет просматривать одну страницу (режим по умолчанию) |
||
|
Две страницы
(Two Page) |
Вид, Число страниц |
Позволяет просматривать две страницы одновременно |
||
|
Несколько страниц (Multiply Pages) |
Вид, Число страниц |
Позволяет выбрать количество отображаемых одновременно страниц |
||
|
Поле со списком Масштаб (Zoom) |
Вид, Масштаб |
Позволяет ввести масштаб отображения в процентах или выбрать его |
||
|
Закрыть (Close) |
Файл, Закрыть |
из списка
Позволяет выйти из режима просмотра и вернуться в режим таблицы или в окно базы данных |
||
|
Установка (Setup) |
Файл, Параметры страницы |
Позволяет изменять параметры страницы непосредственно из режима Предварительного просмотра (см. рис. 2.53) |
||
|
Связи с Office
(Office Links) |
|
Позволяет экспортировать данные из таблицы в другие документы Microsoft Office |
||
|
Окно базы данных (Database Window) |
|
Активизирует окно базы данных |
||
|
Новый объект
(New Object) |
|
Позволяет создать на основе данной или любых других таблиц новую таблицу, запрос, форму, отчет, страницу, макрос, модуль |
||
Слияние с MS Word (Merge It with MS Word) — обеспечивает слияние данных из таблицы Access с документом Microsoft Word;
Публикация в MS Word (Publish It with MS Word) — преобразует таблицу Access в документ Microsoft Word;
Анализ в MS Excel (Analyze It with MS Excel) — преобразует таблицу Access в рабочий лист Microsoft Excel.
Технологические особенности архитектуры системы
Система исходно была реализована в архитектуре клиент-сервер в понимании этого термина системой BTRIEVE и остается такой по сей день. 90 процентов (я думаю, что 99,9%) установок системы сделаны на этой архитектуре (т.е. NOVELL).
Реализация прикладного программного обеспечения на языке высокого уровня теоретически позволяло разработчикам обеспечить работу системы с любым СУБД путем простой подмены базовой библиотеки. Однако, практически, сложность заключается в том, каким набором функциональности базовой библиотеки BTRIEVE пользовались разработчики (BTRIEVE имеет функции обратной прокрутки выборки, которой
не имеется например в ORACLE, а также весьма специфические функции многопользовательской защиты). Таким образом, если система работы с новым СУБД похожа на BTRIEVE, то переход не представляет проблем. Если же это не так, то требуется весьма трудоемкая доработка базовой библиотеки, которая иногда завершается изменением функциональности и необходимостью переписывания исходных программ системы.
Не имею информации о реализации системы на SQL-Server.
Что касается ORACLE, то при запросе одного нашего клиента продемонстрировать систему на ORACLE, представители НОВОГО АТЛАНТА не смогли этого сделать (Морской порт СПБ, лето 1998 года), более того цена на систему на ORACLE оказалась в 7 раз выше, чем на BTRIEVE. В рекламных материалах о версии ГАЛАКТИКИ на ORACLE в основном рассказывается о том, что получит клиент от перехода на ORACLE и ничего о работающей системе.
Система не поддерживает ни трехуровневую архитектуру, ни WEB архитектуру. Вся логика приложения находится на клиенте (правда это не страшно, так как бизнес логика в системе отсутствует).
В заключении, необходимо отметить, что техническая реализация на базе BTRIEVE не позволяет системе манипулировать большими объемами данных и, соответственно, претендовать на Корпоративное решение.
Описание основных функциональных возможностей системы ГАЛАКТИКА
Функции системы ГАЛАКТИКА необходимо оценивать не на основании рекламных материалов с функциональными структурами (очень красивыми!!!), а из содержания прайс-листа со списком подсистем (“контуров”), списком модулей в этих подсистемах и их названий.
В прайс листах, а также презентациях и рекламных материалах, систему представляют, как интегрированную управляющую систему, состоящую из так называемых четырех “КОНТУРОВ УПРАВЛЕНИЯ”. Далее приводятся все эти контуры и модули и проводится сравнение их функциональности с функциональностью ORACLE APPLICATION.
Технология внедрения программ системы 1С:Предприятие (фирма И.К.С. Технологии)
А.В. Поляков, В.Л. Ожигов.
г. Москва, ул. Каланчевская д.29, тел.: (095) 262-1756, 262-9347, факс: (095) 262-0470, info@xtek.ru http://www.xtek.ru
От авторов
В предлагаемом материале представлен вариант технологии процесса внедрения, который мы хотели бы обсудить с коллегами из других франчайзинговых фирм.
По нашему опыту многие внедренцы (особенно начинающие) часто недостаточно четко строят организацию своих внедрений. В комплексных внедрениях проблема организации процесса ведения проекта стоит еще более остро. «Разрывы» в действиях сотрудников фирмы-франчайзи, причастных к выполнению задач автоматизации заказчиков могут привести к ошибкам, затягиванию сроков реализации, недовольству со стороны клиентов и т.п. Т. е. напрямую |могут сказаться на успехе внедрения.
В этой связи, на наш взгляд, назрела необходимость составить определенный набор требований для каждого этапа процесса внедрения, рекомендуемых к выполнению.
Наш материал построен следующим образом.
В начале мы предлагаем общую схему технологии внедрения системы программ 1С:Предприятие. Схема наглядно представляет последовательность выполнения задач. Далее применительно к схеме представлено краткое описание задач и набор типовых действий специалистов фирмы-франчайзи.
Конечно, линейность здесь довольно условна. Задачи могут пересекаться и объединяться. Многие из них растягиваются на несколько этапов. Не всегда представляется возможным выполнение задачи именно в предлагаемой последовательности и т.п.
Хотим выразить огромную благодарность нашим коллегам Жутаевой И., Бушуеву Е., Савину А., Лисогору Д., Мифтаховой М., за помощь в подготовке материала.
Ждем отзывов и предложений. Поляков А.В., Ожигов В.Л. Компания «ИКС Технологии» (г. Москва)
P.S.
При изложении технологии применены следующие ДОПУЩЕНИЯ:
КЛИЕНТ уже ВЫБРАЛ СИСТЕМУ (если это касается внедрений категорий А и Б; см. задачу 7) с помощью грамотных специалистов фирмы-франчайзи и его выбору оказался правильным и рациональным;
ВНЕДРЕНИЕ 1С:Предприятия - оказание франчайзинговых услуг любого объема: от решения частных задач автоматизации до внедрения «в комплексе». Минимальный набор услуг предоставляемых внедренческими фирмами определен Франчайзинговым договором (рекомендации по оказанию услуг см. [1, раздел 2.3], [2, раздел «Типовой набор услуг»]).
Литература, используемая в контексте ссылок:
Технология работы фирмы - «1С:Франчайзи». Д.И. Казачков.
Фирма - 1С:Франчайзи: система обслуживания клиентов. А.В. Поляков, Д.А. Лисогор, В.Л. Ожигов
ТекущаяИБЦентральная
Определить, является ли текущая ИБ центральной.
Синтаксис:
ТекущаяИБЦентральная()
Англоязычный синоним:
1зСиггепЫВСепЬег
Параметры:
Нет.
Возвращаемое значение:
Число: 1, если текущая ИБ центральная, или 0-в противном случае.
Описание:
Функция ТекущаяИБЦентральная возвращает 1, если ИБ, на которой загущена система 1С:Предприята-: - ^--п тральная, и 0 - если периферийная. _
Замечание. функЦИЯ возвращает 1. если ИБ нераспределенная.
Пример:
Если ТекущаяИБЦентральная() = 0 Тогда
Сообщ = "Конфигурация исполняется на периф" ;
Предупреждение(Сообщ, 3);
КонецЕсли;
ТекущаяИБКод
Получить код текущей ИБ.
Синтаксис:
ТекущаяИБКод()
Англоязычный синоним:
CurrentIBCode()
Параметры:
Нет.
Возвращаемое значение:
Строковое выражение, состоящее из трех символов и содержащее код текущей ИБ так, как он задан в диалоге «Управление распределенными данными» Конфигуратора центральной ИБ.
Описание:
Функция ТекущаяИБКод возвращает код ИБ, на которой запущена система 1С:Предприятие.
Замечание. Функция возвращает строку, состоящую из трех пробелов, если ИБ нераспределенная.
Пример:
КодИБ = ТекущаяИБКод();
Если КодИБ = "ЦОФ" тогда
Предупреждение("Конфигурация исполняется на центральной ИБ", 3);
КонецЕсли ;
ТекущаяИБНаименование
Синтаксис:
ТекущаяИБНаименование ( )
Англоязычный синоним:
Параметры:
Нет.
Возвращаемое значение:
Строковое выражение, содержащее наименование текущей ИБ ч;
как оно задано в диалоге «Управление распределенными данным:
Конфигуратора центральной ИБ.
Описание:
Функция ТекущаяИБНаименование возвращает наименование ИБ, на которой запущена система 1С:Предприятие.
Замечание. Функция возвращает пустую строку, если ИБ нераспределенная.
Пример:
Предупреждение("Наименование текущей ИВ - " ТекущаяИВНаименование(), 2);
ТекущаяИБТолькоПолучатель
Определить имеет ли текущая информационная база признак «Только получатель».
Синтаксис:
ТекущаяИБТолькоПолучатель()
Англоязычный синоним:
1зСиггеп<:1ВКесер1еп1:Оп1у
Параметры:
Нет.
Возвращаемое значение:
Число: 1, если текущая ИБ центральная, или О-в противном случае.
Описание:
Функция ТекуэдаяИБТолькоПолучатель возвращает 1, если И Б, на которой запущена система 1 (^Предприятие - имеет признак «Только получатель», и 0 - если нет.
Замечание. Функция ишщыиргт 0. ггтп ИБ нераспределенная. Пример:
Телефонный звонок
Самый распространенный способ получения первичной информации от клиента.
Основная задача сотрудника во время первого телефонной разговора: получить от клиента информацию по «обязательному» перечню вопросов и договориться о встрече с ним или дате и времени следующего телефонного разговора.
Необходимо помнить о том, что клиент позвонил не просто так, ему что-то интересно из того перечня работ/услуг, который предлагает Ваша фирма. В процессе разговора необходимо выяснить, что интересует клиента и не отходить от темы разговора, стараясь предложить ему смежные продукты и услуги.
Идеальным окончанием телефонного разговора с клиентом является просьба клиента выписать ему счет или заключить договор на необходимые программы/услуги. Однако хорошим результатом является достижение договоренности о проведении демонстрации продукта в офисе фирмы или на территории клиента.
Тины партнеров
Партнеры уровня индустриального сервиса являются наиболее существенными для обеспечения рыночного успеха системы. По мере развития системы и перехода партнеров на прикладной уровень сервиса значение проработанной методологии будет возрастать.
Типовая конфигурация
С точки зрения клиента это наиболее экономное и простое решение. К типовым конфигурациям без проблем подходят все исправления и обновления, выпускаемые фирмой «1С». Это решение, с которым можно начинать работать сразу после установки программы на компьютер. Типовые конфигурации «1С» решают основные учетные проблемы, возникающие на небольших предприятиях.
Резюме. Типовые конфигурации подходят для небольших фирм, ведущих типовой учет и не имеющих сильно выраженной отраслевой специфики. Характерным является также тот факт, что используется, как правило, локальный компьютер, либо небольшая локальная сеть, чаще всего с невыделенным сервером.
Требования к аппаратно-программному обеспечению
Компонента «Управление распределенными информационными базами» может быть «доустановлена» в любой момент к любому варианту продуктов семейства 1С: Предприятие 7.7. Наличие такой компоненты является обязательным только для центральной информационной базы. На периферийных информационных базах устанавливается только собственно 1С:Предприятие.
Для обеспечения переноса данных в распределенной системе необходимо иметь возможность физического переноса файлов между рабочими местами, на которых происходит функционирование центральной ИБ и любой периферийной ИБ. 1С:Предприятие предоставляет сервис посылки и приема файлов переноса, однако его использование не является обязательным. Для каждой пары способ физической передачи файлов переноса данных может быть выбран индивидуально.
В остальном требования к окружению компоненты и собственно системы 1С:Предприятие идентичны.
Управление режимами миграции данных внутри распределенной ИБ
Настройка свойств миграции
Корректное использование свойств миграции
Управление структурой распределенной информационной базы
В процессе эксплуатации распределенной информационной базы может потребоваться ее реструктуризация: введение новой или удаление существующей периферийной ИБ, изменение реквизита описания. Коды как центральной, так и периферийной базы изменены быть не могут.
Все изменения структуры производятся только на центральной информационной базе в диалоге «Управление распределенными данными».
Ввод новой периферийной ИБ сводится к созданию образа и инициализации новой периферийной информационной базы. Оба процесса описаны в предыдущих разделах.
Для удаления существующей периферийной ИБ в диалоге «Управление распределенными данными» выберите в списке ИБ удаляемую и нажмите кнопку "Удалить периф. ИБ». Удаление периферийной ИБ приводит к «вычеркиванию» ее из списка периферийных информационных баз на центральной. В ведущих объектах распределенной ИБ, мигрировавших с удаленной периферийной информационной базы, при этом никаких изменений не происходит. С удаленной ИБ можно продолжать работать, как с нераспределенной, однако, в дальнейшем будет уже невозможно снова «подключить» ее к распределенной ИБ, даже если ввести в ее состав новую периферийную информационную базу с аналогичным кодом и описанием.
Центральная ИБ не может быть удалена ни при каких обстоятельствах.
Для редактирования описания центральной ИБ в диалоге «Управление распределенными данными» нажмите кнопку «Центральная ИБ», в появившемся диалоге откорректируйте содержимое поля «Описание» и нажмите кнопку «ОК.».
Для редактирования описания периферийной ИБ в диалоге «Управление распределенными данными» выберите в списке ИБ редактируемую и нажмите кнопку «Выбран. периф. ИБ». В появившемся диалоге откорректируйте содержимое поля «Описание» и нажмите кнопку «ОК.».
Уровень сервиса
Можно выделить три основных группы партнеров по уровню сервиса и числу клиентов. Как показывает опыт, имеется корреляция между уровнем сервиса и числом аттестованных специалистов. Партнеры каждого последующего уровня оказывают услуги предыдущего.
|
1 |
Гарантированный сервис |
Отдельные внедрения |
До 3 аттестованных специалистов |
Доставка Установка Начальное обучение Регулярное обновление Технические консультации |
|
2 |
Индустриальный сервис |
Массовое внедрение |
Более 3 аттестованных специалистов |
Гарантированный сервис + Обследование + Дополнительное обучение + Расширение функциональности + Изменение базы данных + Внедрение + Сопровождение, включая модификации и развитие системы |
|
3 |
Прикладной сервис (разработка приложений под клиента) |
Специальное внедрение |
Несколько групп аттестованных специалистов Группа бизнес реинжиниринга бизнес-процессов Группа разработки |
Индустриальный сервис + Реинжиниринг бизнес-процессов + Полный цикл разработки (либо кардинальная переработка) с использованием инструментальных средств системы |
Дополнительные характеристики партнеров в связи особенностями клиентов представлены в таблице ниже.
|
1 |
Гарантированный сервис |
Индивидуальный клиент |
Базовый Стандартный |
Низкие |
Специалист по вызову |
|
2 |
Индустриальный сервис |
Уровень отдела |
Стандартный Профессиональный |
Средние |
Специализированное подразделение |
|
3 |
Прикладной сервис |
Уровень предприятия |
Профессиональный Комплексный |
Высокие |
Специализированная фирма |
Следует отметить ярко выраженное стремление партнеров к переходу на более высокий уровень. Особенно часто наблюдаются миграции с первого на второй уровень. Партнеры, оказывающие индустриальный сервис, постоянно предпринимают попытки перейти на уровень поставки приложений. Однако зачастую эти попытки оказываются безрезультатными в силу недостаточности потенциала и методической подготовки.
Партнеры уровня индустриального сервиса являются наиболее существенными для обеспечения рыночного успеха системы. Именно с ориентацией на них должна разрабатываться методология внедрения и сопровождения.
Условия эксплуатации
В разделе приводятся конкретные задачи, поставленные перед заказчиком и с решением которых создаются условия для нормальной эксплуатации программ 1С. К ним могут быть отнесены:
обновление технических средств по составу и характеристикам;
наличие необходимого системного программного обеспечения;
обслуживание технических средств;
подготовка персонала.
В дальнейшем, эти условия могут быть использованы при составлении регламентирующих документов по внедрению.
Порядок контроля работоспособности программ и сдача-приемка работ по привязке.
Результаты выполненных работ по привязке должны контролироваться и быть принятыми заказчиком. Контроль и приемка распространяется только на те задачи программы 1С, которые были переработаны или разработаны вновь.
Приемка выполненных работ осуществляется по результатам испытаний на контрольном примере. Контрольный пример должен обеспечить проверку функций задач во всех режимах, а также проверку информационных связей между задачами. Данные контрольного примера должен подготовить заказчик. Специалист проверяет исходные данные, проводит анализ результатов выполнения контрольного примера и исправляет ошибки, допущенные при доработке программ.
В разделе следует привести:
перечень задач, подлежащих проверке на контрольном примере;
объем контрольного примера;
содержание контрольного примера (состав первичных документов, справочники и т. д.);
выполнение контрольного примера;
порядок отражения результатов испытаний;
оформление приемки работ.
Контрольный пример должен охватывать ошибочные ситуации, которые могут возникнуть при эксплуатации программ 1С в результате некорректности исходной информации. Для этого следует использовать искусственно подобранные ошибочные данные для проверки работоспособности программ.
После завершения этапа контроля работы и приемки работ, программы могут быть использованы при внедрении.
Установка
Установка компоненты «Управление распределенными информационными базами» выполняется при помощи специальной программы установки, которая находится на 1-й дискете комплекта поставки компоненты (эта дискета может быть единственной). Перед тем, как приступить к установке, следует убедиться, что жесткий диск не содержит ошибок и имеется достаточно свободного места для выполнения установки. Для установки компоненты требуется около 1,5 Мбайт свободного дискового пространства.
Запуск программы установки. Для установки компоненты необходимо выполнить следующие действия.
1. Вставьте 1-ю дискету комплекта поставки в дисковод А: (или В:).
2. Для запуска программы установки воспользуйтесь одним из следующих способов
• в меню «Пуск» выберите пункт «Выполнить», в выданном на экран запросе укажите имя программы установки, например:
и нажмите кнопку «ОК»:
или
• запустите программу Панель Управления (Пуск - Настройка - Панель Управления) и щелкните мышью на пиктограмме «Установка и удаление программ». Выполняйте дальнейшие действия по выдаваемым на экран указаниям.
После выполнения подготовительных действий на экран будет выдано главное окно программы установки компоненты «Управление распределенными информационными базами». Дальнейшие действия выполняйте по указаниям программы установки компоненты.
Установка и подключение компоненты
Требования к аппаратно-программному обеспечению
Установка
Защита от копирования
Подключение
Варианты входящей информации
Всю поступающую в фирму-франчайзи информацию можно условно разделить на три основных канала: телефонный звонок, письменное обращение, контакт на выставке. Ниже мы более подробно рассмотрим каждый из каналов получения информации.
Необходимо отметить один аспект, общий для всех случаев общения с клиентом: вежливость. Вне зависимости от Вашего настроения, загруженности, наличия неприятностей и т.д., разговор с клиентом должен быть предельно вежливым и доброжелательным. Всегда действуйте по поговорке - «относись к людям так, как хочешь, чтобы они относились к тебе».
Входящая информация
Вся деятельность фирмы-франчайзи, связанная с внедрением, начинается с получения входящей информации. Мы уверены, что от полноты информации, полученной во время первого контакта, зависит очень многое.
Внедрение
Все работы у клиента можно разделить на две достаточно большие группы работ: работы «по часам» и работы «по перечню работ». Более подробно с принципами разделения можно познакомиться в главе 3.5 книги [I]. Здесь мы остановимся на ключевых моментах работы по тому или иному принципу у клиента.
Перед началом работы у клиента, сотрудник обязан точно знать, на каких условиях он работает у заказчика (обязательно знать условия оплаты - «по часам» или «по перечню работ», какой объем работ необходимо выполнить, какое подразделение мы автоматизируем и т.д.). Однако совершенно нет необходимости посвящать сотрудника в финансовые тонкости договора (сумма договора, условия оплаты и т.д.). Если Вы проводите крупное внедрение, то обязательно должен быть сотрудник, который руководит работами, и через которого решаются все ключевые вопросы с клиентом.
Если оплата данного внедрения ведется «по часам», то необходимо, чтобы сотрудник вел листы учета рабочего времени. Без этого будет невозможно выставлять счета на оплату рабочего времени специалиста.
Если внедрение ведется по «перечню работ», то следует строго выполнять последовательность этапов при внедрении:
предварительные переговоры;
подготовка технического задания;
внедрение системы;
обучение и сопровождение готовой системы
Соответствующие формы документов (коммерческое предложение, договор на внедрение по часам, договор на создание перечня работ и плана-графика, договор на внедрение по перечню работ, акт приемки-сдачи работ и договор на сопровождение) Вы можете найти в главе 7 книги [I]. Исключение составляет лист учета рабочего времени, который не приводится в книге [I]. Форма этого документа приведена в главе 0 данной книги.
Если в фирме выделен специалист, который руководит процессом внедрения у данного заказчика, то все документы (кроме финансовых) подписывает этот специалист. В сферу его ответственности также входит решение большинства организационных и технических вопросов, связанных с выполнением работ у клиента. К таким вопросам относятся:
разрешение конфликтных ситуаций;
подписание промежуточных актов выполненных работ;
согласование и подписание технического задания (или перечня работ);
принятие решения о дополнительных (к объему технического задания) работах и определения их статуса - платные или бесплатные. Если работы платные, то происходит согласование содержания работ, сроков их выполнения и объемов дополнительных платежей.
Если на каком-то внедрении нет такого выделенного специалиста, то решение об объеме дополнительных работ принимает непосредственно тот сотрудник, который выполняет работы у заказчика, после обязательной консультации с руководителем подразделения, в котором он работает.
Внешний вид
Сотрудник, работающий с клиентом, должен выглядеть так, чтобы не создавать дискомфорта при общении с собой. Одежда должна быть чистой и выглаженной, ботинки должны быть начищены, человек должен быть причесан, аккуратно побрит. В целом можно сказать, что человек должен выглядеть так, как его ожидает увидеть клиент. Если в организации принят свободный стиль одежды, то допустимо прийти в джинсах. Если у заказчика принято ходить в костюме, то также правильно будет одеть для визита к нему деловой костюм.
Вставка, удаление и переименование полей таблицы
Вставка, удаление и переименование полей таблицы
Рассмотрим теперь, каким образом можно переименовывать, вставлять и удалять поля в режиме Конструктора таблиц.
Чтобы переименовать поле в режиме Конструктора таблиц, необходимо:
-
Щелкнуть левой кнопкой мыши в столбце
Имя поля
(Field Name) на имени поля, подлежащего переименованию.
Ввести новое имя поля или отредактировать старое имя.
Нажать клавишу <Enter> или переместить указатель текущей записи на любую другую запись.
нажать кнопку Добавить строки (Insert Rows) на панели инструментов Конструктор таблиц (Table Design);
выбрать в главном меню команду Вставка (Insert) и из раскрывающегося меню выбрать команду Строки (Rows);
щелкнуть правой кнопкой мыши на выделенной записи и из контекстного меню выбрать команду Добавить строки (Insert Rows).
Затем в полученную пустую строку нужно ввести имя нового поля, тип и описание.
Замечание
Чтобы вставить сразу несколько строк, необходимо выделить требуемое количество существующих строк, перед которыми нужно вставить новые, а затем выполнить команду вставки строк в соответствии с приведенной выше процедурой.
выбрать из главного меню команду Правка (Edit) и из раскрывающегося меню — команду Удалить (Delete) или Удалить строки (Delete Rows);
нажать на клавишу <Delete>;
щелкнуть правой кнопкой мыши на выделенной строке (строках) и из контекстного меню выбрать команду Удалить строки (Delete Rows).
Замечание
При удалении полей, в которых содержатся или могут содержаться данные, Microsoft Access потребует подтверждения на удаление данного поля.
-
Выделить столбец, который необходимо переименовать. Для этого нужно щелкнуть левой кнопкой мыши на имени поля (столбца).
Щелкнуть правой кнопкой мыши на выделенном столбце и из контекстного меню выбрать команду Переименовать столбец (Rename Column) или выбрать из главного меню команду Формат (Format) и из раскрывающегося меню — команду Переименовать столбец (Rename Column).
В поле заголовка столбца ввести новое имя поля и нажать клавишу <Enter> или щелкнуть левой кнопкой мыши в любом другом месте таблицы.
Для быстрого переименования поля в режиме Таблицы можно дважды щелкнуть левой кнопкой мыши в поле заголовка столбца, ввести новое имя поля и нажать клавишу <Enter>.
-
Выделить столбец, перед которым требуется вставить новое поле.
Щелкнуть правой кнопкой мыши на выделенном столбце и из контекстного меню выбрать команду Добавить столбец (Insert Column) или из главного меню выбрать команду Вставка (Insert) и из раскрывающегося меню — команду Столбец (Column).
Чтобы удалить поле из таблицы в режиме Таблицы, необходимо:
-
Выделить столбец, который нужно удалить.
Щелкнуть правой кнопкой мыши на выделенном столбце и из контекстного меню выбрать команду Удалить столбец (Delete Column) или выбрать из главного меню команду Правка (Edit) и из раскрывающегося меню — команду Удалить столбец (Delete Column).
Какие задачи решает компонента
Структура Руководства
Что вы должны знать
Принятые обозначения
Используемые термины и сокращения
Какие задачи решает компонента «Управление распределенными ИБ»
Настоящая книга является Руководством по использованию компоненты «Управление распределенными ИБ».
Компонента «Управление распределенными ИБ» является необязательной частью системы 1С:Предприятие. Она реализует механизм работы системы 1С:Предприятие с распределенной информационной базой при любом составе установленных компонент 1С:Предприятия.
Данное руководство описывает работу компоненты «Управление распределенными ИБ» со всеми компонентами 1С:Предприятия («Оперативный учет», «Расчет», «Бухгалтерский учет»).
Заметим, что в компонентах «Бухгалтерский учет» и «Расчет» используются дополнительные объекты, для которых приводится описание их работы в распределенной ИБ. Если какая-либо из компонент «Бухгалтерский учет» или «Расчет» не установлена, то соответствующие ей объекты не используются и никак не влияют на функционирование системы.
В перечне основных услуг фирмы- фраичайзи выделяются два вида, по трудоемкости и сложности, нередко превосходящие остальные - это привязка и внедрение программ 1С. Кроме того, привязка и внедрение отличаются еще одной существенной деталью. При их выполнении, в процессе перевода предприятия (организации) на автоматизированный учет принимают участие и учетный персонал организации и специалисты франчайзи, т. е. появляется "человеческий фактор". В тоже время услуги другого рода продажа программных продуктов, доставка, установка, консультационные услуги и ряд других, характерны тем, что функции франчайзи и клиента четко разделены, и франчайзи не несет ответственности за процесс автоматизации учета на предприятии (организации) с использованием программ 1С.
Ввод данных с помощью копирования и перемещения
Ввод данных с помощью копирования и перемещения
Ввод данных в таблицу можно осуществлять не только непосредственно с клавиатуры, но и с помощью команд копирования и перемещения. Для того чтобы вырезать или скопировать текст, необходимо выделить его и нажать на соответствующую кнопку на панели инструментов: Вырезать (Cut) или Копировать (Сору). При этом выделенная информация будет перемещена или скопирована в буфер обмена. Чтобы вставить скопированную информацию, следует установить курсор на то место, куда ее предполагается вставить, и нажать кнопку Вставить (Paste) на панели инструментов.
Замечание
В таблице Access можно так же, как в рабочем листе Excel, выделить диапазон ячеек (рис. 2.38). Для этого нужно сначала подвести указатель мыши к левой границе левой верхней ячейки, дождаться, когда курсор примет форму крестика, после этого нажать левую кнопку мыши и, удерживая эту кнопку, переместить указатель в нижнюю правую ячейку и отпустить кнопку мыши.
Ввод и проверка данных
До сих пор мы обсуждали все вопросы, связанные с созданием таблиц, определением и изменением их структуры. Эти изменения выполняются в режиме Конструктора таблиц. Теперь мы переходим к описанию возможностей, которые предоставляет Access при работе с таблицами в режиме Таблицы. Этот режим связан с вводом и обновлением данных в таблице.
Выгрузка и загрузка данных
Ручная выгрузка и загрузка на периферийной ИБ
Ручная выгрузка и загрузка на центральной ИБ
Автообмен на периферийной ИБ
Автообмен на центральной ИБ
Выполнение автообмена в пакетном режиме
Для осуществления переноса данных в системе необходимо организовать периодический обмен файлами переноса данных между центральной и периферийными информационными базами. Периодичность этого процесса, очередность обслуживания периферийных ИБ и физический носитель для файла переноса системой не регламентируются - решение этих вопросов остается за пользователем и зависит от конкретных обстоятельств: необходимости иметь в центральной ИБ полную картину состояния предприятия к определенным моментам времени, наличию аппаратных и программно-аппаратных средств, при помощи которых обмен организуется и т. д. Использование встроенной возможности автообмена с помощью электронной почты не является обязательным. Система ведет себя устойчиво при возможных сбоях в организации процесса переноса данных. Файлы можно загружать не в том порядке, в каком происходила их выгрузка, производить попытку повторной загрузки, пытаться принять файл, предназначенный для другой ИБ, даже «потерять» один или несколько файлов переноса данных (кроме файла первичной выгрузки) - распределенная ИБ будет функционировать корректно.
Данный раздел поясняет, как выгрузить и загрузить файл переноса данных, не касаясь вопросов, связанных с организацией доставки файла от одного рабочего места распределенной системы к другому.
Ручная выгрузка и загрузка файла переноса данных осуществляется в диалоге «Управление распределенными данными» Конфигуратора. Процесс автообмена запускается из диалога «Автообмен» Конфигуратора. Кроме того существует возможность выполнения автообмена в пакетном режиме, то есть без участия пользователя.
Режимы управления распределенной ИБ и автообмена не следует запускать параллельно с работающей в монопольном режиме системой 1С:Предприятие, так как при попытке вызвать диалог управления распределенными данными будет выдаваться сообщение об ошибке, связанной с блокировкой данных. Если 1С:Предприятие работает в разделенном режиме (в многопользовательских версиях), то существует возможность выполнения выгрузки и загрузки изменений. При обращении к режимам управления распределенной ИБ и автообмена будет выдаваться предупреждение об ограниченности выполняемых функций. Разумеется, загрузка изменений в разделенном режиме невозможна, если загружаемые изменения включают измененную конфигурацию.
Для вызова диалога «Управление распределенными данными» за кройте все открытые окна Конфигуратора и выберите пункт меню «Администрирование/ Распределенная ИБ/ Управление». Для вызова диалога «Автообмен» закройте все открытые окна Конфигуратора и выберите пункт меню «Администрирование / Распределенная ИБ/ Автообмен». В силу особого положения центральной базы враспределенной системе, вид диалогов для периферийной базы и процесс выгрузки-загрузки имеют существенные различия.
Выполнение автообмена в пакетном режиме
Часто используемые административные функции 1:Предприятия могут выполняться в пакетном режиме. Это позволяет выполнять их без участия пользователя. Подробно пакетный режим описан в книге «1С:Предприятие. Конфигурирование и администрирование». В данном разделе приводится описание секции файла параметров пакетного режима, предназначенной для задания параметров автообмена в распределенной ИБ.
Секция AutoExchange [AutoExchange]
Данная секция предназначена для описания выполнения автообмена распределенной информационной базы.
| Параметр | Пояснение | ||
| SharedMode=Значение | Параметр указывает, следует ли запускать процедуру автообмена в разделенном режиме, если нет возможности открыть нформационную базу монопольно.
Если задано У или 1, то автообмен може быть выполнен в разделен- ном режиме, если же 0 или N. то автообмен будет выполняться только в монопольном режиме. Если параметр не задан, то автообмен будет выполняться только в монопольном режиме. | ||
| ReceiveFrom=Список_кодов_ИБ | Параметр задает список кодов И Б. для которых в процессе автообмена должна быть выполнена операция приема сообщений по электронной почте. Список задается как перечень кодов И Б, разделенных пробелами или запятыми.
Если необходимо, чтобы действие было выполнено для всех ИБ, в качестве значения параметра следует использовать символ *. Кроме того, символ * может быть использован для указания всех информационных баз имеющими в начале кода один или два общих символа, например СК*. | ||
| ReadFrom=Список_кодов_ИБ | Параметр задает список кодов ИБ, для которых в процессе автообмена должна быть выполнена загрузка измененных данных. Список задается как перечень кодов ИБ, разделенных пробелами или запятыми. Если необходимо, чтобы действие было выполнено для всех ИБ, в качестве значения параметра следует использовать символ *.
Кроме того, символ * может быть использован для указания всех информационных баз имеющими в начале кода один или два общих символа, например СК*. | ||
| WriteTo=Список_кодов_ИБ | Параметр задает список кодов ИБ, для которых в процессе автообмена должна быть выполнена выгрузка измененных данных. Список задается как перечень кодов ИБ, разделенных пробелами или запятыми.
Если необходимо, чтобы действие было выполнено для всех ИБ, в качестве значения параметра следует использовать символ *. Кроме того, символ * может быть использован для указания всех информационных баз имеющими в начале кода один или два общих символа, например СК*. | ||
| SendTo=Список_кодов_ИБ | Параметр задает список кодов ИБ, для которых в процессе автообмена должна быть выполнена операция отправки сообщений по электронной почте. Список задается как перечень кодов ИБ, разделенных пробелами или запятыми.
Если необходимо, чтобы действие было выполнено для всех ИБ, в качестве значения параметра следует использовать символ *. Кроме того, символ * может быть использован для указания всех информационных баз имеющими в начале кода один или два общих символа, например СК*. |
Ниже приводятся выводы, имеющие наиболее
Ниже приводятся выводы, имеющие наиболее существенное значение для разработки методологии внедрения системы "1С:Предприятие".
Выводы по “контуру”
Просмотрев данную подсистему, остается открытым вопрос: “При чем тут управление?”. Данные модули ни с чем (в системе) не связаны и ничем не управляют.
По-видимому, ставилась цель закрыть функции печати табличек в соответствующих отделах (маркетинга и т.д.), а главное маркетинговая цель наличия такой подсистемы. Я бы сказал, что EXCEL с этим справляется лучше.
Наиболее ценной, с практической точки зрения, является система Управления персоналом. В ORACLE APPLICATION все эти функции представлены гораздо шире, лучше структурированы и действительно имеют управляющий характер. Бизнес-план в Финансовом анализаторе преобразуется в Бюджет и загружается в главную книгу не для красоты, а для контроля исполнения.
Анализатор продаж, Финансовый анализатор и Sales & Marketing позволяют провести анализ тенденций по соответствующим направлениям и принять решения об изменении соответствующей бизнес процедуры, которая поддерживается системой. Например, изменить системы оплаты по договорам с определенной группой заказчиков и главное обеспечить чтобы эта процедура выполнялась.
Управление Проектами является действительно управлением проектами, с практически всеми функциями, необходимыми для данного типа производства.
Необходимо отметить, что данный “контур” является наиболее дорогим в системе (Unlimited license - 32990$). Я бы сказал, что руководство ГАЛАКТИКИ, хочет либо быстро покрыть затраты на разработку, либо не хочет продавать эти модули.
Система проектировалась в Советские времена и тупо реализует журнально-ордерную систему бухгалтерского учета. При этом за основу брались не задачи автоматизации, а так называемые требования пользователей. Т.е. система построена так, чтобы ни в коем случае не был сокращен ни один человек из бухгалтерии. Поясняю. Журнально-ордерная система учета была разработана для РУЧНОГО учета первичных документов. При этом каждый документ обрабатывался как минимум двумя разными бухгалтерами (например, один вел журнал-ордер по дебету 10-го счета, другой ведомость по кредиту 60-го счета для одних и тех же документов - приход на склад). Затем заместитель главного бухгалтера заполнял главную книгу (ШАХМАТКУ). Верхнюю половину на основании журналов-ордеров, а нижнюю - на основании ведомостей. При этом тут же выявлялись ошибки, так как эта матрица должна была быть симметрична. Это и было основной целью журнально-ордерной системы учета. Безусловно, ГАЛАКТИКА не формирует двойных проводок, однако структура системы осталась. Но даже в Советские времена в учебниках говорилось, что существует журнально-ордерная система и автоматизированная система,
на которую стандартные правила не распространяются (лишь бы получалась отчетность).
Главным недостатком системы, на мой взгляд, является то, что она фактически не интегрирована, т.е. бухгалтерский учет сам по себе, оперативный учет сам по себе. Однако структура и метод работы в системе ОЧЕНЬ нравится бухгалтерии и некоторым руководителям (так похоже, никого не сократят и ОЧЕНЬ “гибко”).
Основными достоинствами ORACLE APPLICATION по сравнению с ГАЛАКТИКОЙ являются:
автоматическое формирование проводок и ГАРАНТИРОВАННОЕ соответствие оперативного
и бухгалтерского учета.
проверка бюджета и возможность блокировки при проведении любой операции.
бухгалтерский учет, проверка по бюджету и возможность блокировки будущих операций (например, заявок на снабжение)
возможность планирования денежных средств
отслеживание бизнес-процедур при проведении любого документа (например, невозможность ввода документа без утверждения с суммой превышающей лимит для конкретного бухгалтера)
В целом система ГАЛАКТИКА очень примитивна и не реализует никаких функций Финансового управления (т.е. планирования и контроля операций). Среди Российских систем есть системы на порядок лучше (ОМЕГА, БОСС, даже до определенной степени 1С).
Заказная конфигурация
Это самый сложный вариант при выборе конфигурации нашей системы. При создании заказной конфигурации обязательным является проведение создание технического задания, в котором будут учтены все нюансы и аспекты деятельности автоматизируемого предприятия. По нашему опыту, объем технического задания может варьироваться от пяти до 300-500 страниц текста. Понятно, что основой для заказной конфигурации может быть:
типовая конфигурация фирмы «1С»;
любой ТОР;
ни один из вышеперечисленных пунктов, т.к. конфигурация будет создаваться «с нуля».
Причем в любом случае основой может служить не одна, а несколько конфигураций. Например, конфигурации «1С-Рарус: Производство» и «lC-Papyc:GAAP», могут использоваться для автоматизации производства, в котором есть доля иностранного капитала.
Следует четко определить схему оплаты при создании заказной конфигурации. Подробно этот аспект внедрения рассмотрен в главе 3.6 книги [I].
Резюме. Данный метод характерен для предприятий, обслуживание которых либо не укладывается в готовые решения, либо являются комбинацией готовых решений с существенной доработкой. Компьютерная сеть почти всегда имеет выделенный сервер. По опыту «IC-Papyc» достаточно часто в таких случаях применяется SQL-серверная версия «1С:Предприятия».
Защита от копирования
Для предотвращения возможности незаконного тиражирования компонента «Управление распределенными информационными базами» предоставляется пользователям в защищенном от копирования виде.
Одной из составных частей используемой системы защиты является аппаратный ключ, который необходимо вставить (разумеется, при выключенном компьютере) в разъем параллельного порта компьютера. Если вы используете принтер, кабель от него надо вставить в другой разъем ключа защиты. Наличие ключа не влияет на функционирование компьютера и его взаимодействие с принтером - вы можете использовать принтер так же, как обычно.
Рекомендуется размещать ключ защиты компоненты там же, где находится ключ защиты системы 1С:Предприятие.
Завершение
| ПП-УС-080 | Высвободить персонал | Высвобожденный персонал |
| ПП-УС-090 | Высвободить физические ресурсы | Высвобожденные физические ресурсы |
| nn-УК | Управление качеством |
| пп-УК-050 | Комплексная оценка качества | Отчет о качестве |
| nn-УФ | Управление конфигурацией |
| пп-УФ-060 | Провести аудит ключевых результатов | Аудированные результаты | ||
| пп-УФ-070 | Завершение управления конфигурацией и передача соответствующих функций клиенту | Работоспособная система управления конфигураций, переданная в использование клиенту |
