Технологични инструкции какво се нуждаят и какво представлява

Общи въпроси, документиращи

Техническа комуникация: условието на задачата

Документация на системи и ИТ инфраструктура

Стандарт 34

Защо Стандарт 19 и Стандарт 34

Автоматизирана система от гледна точка на ГОСТ 34

Автоматизирана система от гледна точка на ГОСТ 34. Продължава

Призрак на ГОСТ

Поставяне на документ "за код за достъп"

документиране на инфраструктури

Документиране ИТ инфраструктурата на организацията

процес документиране

Обработка инструкции: защо те са необходими и че представляват?

Когато е необходимо да се започне регулирането на дейността и на прехода към обичайното управление?

управление на документи

Подход за оценяване на условията на създаване на техническа документация

Техника и стил на представяне

Каква трябва да бъде ръководството на потребителя

Как е устроен светът? Концепция част от инструкцията за употреба

Как се пише документация на английски език?

инструменти

Разработване на техническа документация, въз основа на един-единствен източник

Напишете с бухалка файлове могат всеки!

Налудничав Flare: система за разработване на техническа документация, въз основа на един-единствен източник

Илюстрирана каталог на части и възли по стандарта S1000D

Microsoft Word

Microsoft Word за техническа писател

Препоръки за системата за стил в шаблони за техническа документация

DITA

DITA технология: преглед на функциите и основните предимства

Изисквания към документацията, използващи DITA

DocBook / XML

DocBook / XML: отворена платформа за разработване на техническа документация

Персонализиране на външния вид на изходните документи в DocBook / XML

Създаване FO-процесори за показване на символи на кирилица в средата на Microsoft Windows

CMDB Документи

Diagrams "стимул-реакция" - алтернатива на традиционния модел на бизнес процесите

документация проблеми с персонала

Кои са технически писатели?

Технически писател. Основна професионална компетентност

Технически писател в големия свят, специалност и професия >>

стандартизация

Гостите на проекта на стила

ANSI Z535.6 - стандартно предупреждение вратовръзки в техническата документация

мерки

Конференцията "Документиране днес"

Въведение в DITA. уебинар запис

превод

А. Klimenko. превод Craft >>

Шапка и CAT

друг

Как се пише курсова работа и не глупости нечии панталони на ушите

Humane работа в Microsoft Excel

Както убедителни оценка, планиране и отчет с цифри,

Предистория на технологията на документ

Технологична инструкция - един от оперативни документи, предоставени от серия държавни стандарти 34. Спомнете си, че тази серия от стандарти за автоматизирани системи (AS), по-специално, тяхната документация. Често такъв документ се нарича още регламенти, както и на длъжностната характеристика, но последната опция ни изглежда нелепо, а дори и заблуждаваща, тъй като длъжностни характеристики са HR отдели и служат напълно различна цел.

Според определението, дадено в ГОСТ 34.003-90, AC задължително включва хардуер, софтуер и персонал. Пример, Microsoft Excel като такъв - е софтуерен продукт, и секретаря, който седи пред компютъра и пишат по определен начин маркирани маси входящи повиквания - АС, макар и доста малък. За описание на софтуера са документи, като например управление на потребителите, Ръководство на системния администратор (след писмото на стандарта - системен програмист) Ръководство на програмиста. Има различни документи, описващи технически средства. Технологична инструкция - "най-хуманно" документ, той описва действията, които участват в работата на персонала на АС, с други думи, потребителите. Това е формален аспект на въпроса.

По този начин, проблемът на технологични инструкции - корелира функционалността на софтуера на автоматизираната система с практиката, описва работата на членовете на АС по същество.

Да назовем само няколко причини за такова решение може да бъде неуспешен.

На първо място, със същите функции на софтуера могат да се използват от различни служители при изпълнение на различни операции. Ще ходим ли да се опише всяка операция, многократно повтарящи се описания на същите софтуерни функции? Ако е така, тогава документът ще расте силно в силата на звука. Ако не, описанието на тези описания ще трябва да "направи скобите": поставете ги в специални секции от някъде в началото на документа и да осигури връзки към тези секции на секциите, описващи работата директно. Но такова решение е равносилно на писане на два документа, събрани под един капак!

На второ място, има програми, които са от време на време са в процес на финализиране, а има и организации, в които се провеждат реформи. Какво едно нещо може да бъде значителна изменчивост друг. Събиране на програмно и организационно участие в един документ, ние го направи по-трудно да се актуализира и да се хармонизират, особено като се има предвид, че част от програмата да се наложи да преговаря с разработчиците и институционални мениджъри. Представители на всяка "фракция" в този случай ще трябва да работят през много неща, че няма пряка връзка с него. В допълнение, често се случва, че след монтажа и изпълнението на официална стабилизира като цяло да практикуват работа, за да се разклаща надолу от доста време. След технологичните инструкции, разработени много по-късно документация на програмата, както и въз основа на информация, предоставена от потребителите, тъй като, а не от нейните разработчици.

Трето, съществува риск, че в резултат на сливането документ за дърветата в гората се вижда. Претоварен с технически подробности за по-голямата част от текста на потребителя ще бъде трудно да се реда на изпълнение на операцията се изолират. Последното може да предотврати и даване на статут на технологичните указания на организационни и административни документи. Пълен фолио пълна с "снимки на екрани", таблици и подробни процедури, е трудно да се одобри реда и да се даде за преглед под картината.

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

Технологична инструкция, като правило, се определя до определена функционална роля. Ако мениджър продажби един говорител, счетоводител, складодържателя, секретарка, а след това за всеки от тях има своя собствена писмена инструкция за употреба. Тя дава описание на тези и само тези операции, които са характерни за един-единствен тип потребител.

Отделно от услуги и уводните секции, ръководство за употреба е колекция от описания на операции. Всяка операция е описана в отделен раздел (раздел, точка - в зависимост от конкретната структура на документа). Желателно е, че последователността, описана в документа, съответстващ на последователността на самите операции в живота, но това не винаги е възможно, поради различни причини.

Сега е необходимо да се изясни какво се разбира под операцията. Ние призная веднага, че строго официална дефиниция на операцията имаме, но има свободен описание, което позволява да се разграничи тази концепция.

Операция, която наричаме съгласувани действия извършени от едно лице, за ограничен период от време и води до резултат, смислен всички средства, за да го постигне. Клиента за таксуване - на работа. Защо? На първо място, от страна на клиента трябва да бъде изписано във всеки случай, дори ако АС означава, че перо писалка върху пергамент. На второ място, получаване на клиентска сметка означава, че в отношенията ни с него беше определена промяна. Напротив, влизащи подробности за клиента в областта на екран "Профил", или не се отпечатват операции представляват същите причини, че операцията не е по потапяне гъши пера в мастилницата.

Независимо от стила и дизайна на описание, за да опише операции са непременно едно от следните колони или колони:

  • Trigger, т.е. събитие или обстоятелство, при настъпването на които потребителят извършва операцията. Задействането може да бъде всеки външен за събитието потребител (лечение на контрагента, друг служител, на разположение на началника, пристигането на документ или съобщение), появата на определен момент за определен график, или чрез персонализирано решение. Изброяват тригери, за да опише операцията е необходимо, защото никой в ​​правото си ум и с памет не се хвърлят към сметката без видима причина. Ако не кажете на потребителя, когато той трябва да направи операция, тя няма да го направя никога.
  • В резултат на операцията, т.е. значителна промяна в ситуацията, която се появява след успешната му реализация. Резултатът не трябва да се бърка с изходните данни или документи. Така че, истинската резултат на фактурата не е на хартия, а задължение и / или клиентът може да си позволи да ни плати, е необходимо да се проследи предлагането на пари по сметка, резервацията на стоката, когато става въпрос за отчитане на авансово плащане и т.н.
  • Стъпка по стъпка описание на операцията, и количеството на детайли характеристики, които до голяма степен определят AU. Въпреки това някои от неговите характерни черти могат да бъдат идентифицирани. Всяко описание стъпка се отнася до една единствена проблем да бъде решен чрез Софтуерът и "реалния свят". Например, един обект може да е екран на разговор във форма и входни данни към него. Търсене хартиено копие на документа, върху скарата също може да се разглежда като отделна стъпка, не само решение за автоматизиране на задачи. При описанието на автоматизирани и не-автоматизирани задачи, ние се опитваме, доколкото е възможно, за да се намали количеството на технически подробности. Описвайки, да речем, попълване на формуляр, посочете кои полета са задължителни, може да доведе до "снимки" на попълнения формуляр, но описанието на желаните възможности за търсене елемент в указателя или календар за дата вход вече е излишно, тази информация е мястото, в ръководството на потребителя или в контекста на помощта.

Описание на операцията може да бъде допълнен с други полезни функции. След това има смисъл да се уточни как да се провери за успеха на операцията, и в същото време да се обясни какво да правите, ако операцията се провали. Случва да бъде една и съща операция като в зависимост от случая, или трябва да се извършва по същество по много начини, това е, разбира се, трябва да бъдат отразени в описанието му. Всичко това по-подробно и движение на необходимия минимум за информационното претоварване.

Технологични инструкции и описания на бизнес процеси

Какво е различен от ръководството с инструкции, описващи бизнес процесите? В действителност, тези два документа казват за операциите, само по различни начини са групирани. В описанието на операциите по бизнес процеси, събрани от принадлежност към този бизнес процес и технологичната инструкция въз основа на тяхното изпълнение носител на функционална роля. Изглежда, че ако ние "рязани" всички технологични инструкции, за отделни транзакции, а след това получените фрагменти ще бъде възможно да "лепило" описанието на всички бизнес процеси. В някои случаи това е вярно, но на практика често се случва, че част от технологични инструкции, можем да сравнително лесно и задоволително описание на бизнес процеси се превръща в цел трудно да се постигне.

Членове и техния отговор на различни събития съществуват обективно. Ние можем да задам един конкретен мениджър или счетоводител, "При какви обстоятелства бихте бъдете таксувани? Защо правиш това? Какво се случва, след като го направи? ", А той може да даде на този въпрос е ясен, макар и не винаги лаконичен отговор.

Бизнес процеси, а напротив, е субективно, той е един от хората, разработени начини за описване на собствените си дейности. Не случайно по време на парти Series 34 тази концепция не е, но там е по-широко понятие от модела на информация. Информация модели могат да излезе с много по-различна. Ние можем да се опише с продажбата на стоки до клиента като процес и може като жизнен цикъл на поръчка, направена от клиента, като се позовава на последния като своеобразен обект ( "преговарям"), преминаване на пътя, очертан.

Поради случайността и произвол има място винаги абсолютно ясно, строго повторяеми бизнес процеси вероятно няма да намерите никъде другаде. Използването на понятийния апарат на бизнес процесите, ние сме в състояние да не описват реалността, но фактът, че има, и трябва да се случва глоба. Нормата е, от една страна, винаги има някой предполага, и второ, трябва да се вземат по време на това мнозинство. В много организации, последователното представяне на нормата не съществува (човек погледне на ситуацията от тяхна страна), така че който и да е описание на бизнес процеси се откъсне голяма част от екипа.