Общ преглед

Този запис описва един казус, който описва действителната MRO (Поддръжка, Ремонт и операции) работния поток одобрение процес в MOSS.

Това не е откровено техническа дискусия, но вместо това служи да осигури действителен свят пример, който показва как платформата на Мос срещна реални трябва.

(Този запис е кръстосано публикувани между http://paulgalvin.spaces.live.com и http://blogs.conchango.com)

Фон

На клиента MRO процес са се характеризират със следното

• Ръчно одобрение процес.
• Някои поддръжка using Превъзхождам spreadsheets.
• Нередовни одобрение процес. Процесът на одобрение на същото MRO закупуване ще варират ден за ден, лице от лице.
• Много хартия и саморъчните подписи — закупуване на заявки изисква до 3 писмени подписи преди окончателното одобрение.

Целите на проекта бяха осъществени:

• Напълно автоматизира процеса на.
• Прилагат корпоративни стандарти за одобрение.
• Предоставя обобщен изглед на MRO закупуване на различни мениджъри.
• Подробна одитна пътека.

Като страничен ефект на разтвора, писмени подписи вече не са необходими.

Процес на одобрение

Процесът на одобрение се състои от четири "плува платна": Предприятията за оригинални, Пряк ръководител, Функционални мениджър и разделението мениджър.

Предприятията за оригинални:

Климушка определителен член нужда за покупка и започва процеса. Обърнете внимание, че наредителят може или не може действително да влезе заявка за покупка, но вместо това пряко друг служител да го направят. Някои пъти, Авторът не разполага с техническа експертиза за попълване на PO заявки. За пример, Потребителят може да искате да заявка нов преносим компютър, но не знае най-добър доставчик, IT стандарти, н. В този случай, Авторът работи с нея и тя действително се попълва заявка.

Пряк ръководител:

Това е пряк ръководител на автора (които могат да бъдат различни от лицето, което действително са били пуснати на PO заявки в Мос). Преките ръководители трябва да одобри на PO заявки, преди системата да потърси одобрение допълнително установяване на ред.

Функционални мениджър:

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

Разделението мениджър:

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

Решението

Ние използвахме следните инструменти и компоненти за изпълнение на решението:

МОС: Служи като платформа, от която всичко останало "увисва". Мос предоставя здрава основа услуги за сигурност, главни данни, одит и други функции.

Услуги за формулярите на InfoPath: Мос компонент, Това дава възможност на потребителите да попълват покупка искания чрез уеб браузър.

SharePoint Designer (SPD): Ние използвахме SPD да приложат процеса на автоматизиран работен процес.

Уеб услуга: C# уеб услуга подобрява работата на потребителите като даде възможност на каскадни селекции списъци в InfoPath форма и осигурява по-добра производителност спрямо филтриране на данни. Вижте Тук за технически дълбоко гмуркане по този въпрос и причини за използването му.

Потребителски списъци: Мос потребителски профили предоставя пряк ръководител на даден потребител, но не предостави повечето от данните, които контролират работния поток решения (e.g. дали дивизионен мениджър се изисква да одобри на PO заявки). Използвахме потребителски списъци в "корпоративни данни" сайт за поддържане на данните като "Дивизионен мениджър одобрение сума за долар", "Функционална област мениджър" и така нататък. Списъци интегрирани много добре с InfoPath и също така предоставя създаване/актуализиране/изтриване (CRUD) функционалност за одит и сигурност на кутията.

Случай употреба

Този употреба случай илюстрира как решението се вписва заедно:

1. Paul иска нов лаптоп. Той описва нуждите му да Vivek, човек запознат с корпоративен лаптоп стандарти, Предпочитани доставчици, н.
2. Вивек трупи в Мос, достъп до формуляра PO заявки и навлиза заявки от името на Paul. Формата подканва Вивек за покупка категория, които след това използва уеб услуги да се пренесат капка-голо възвишение списък на фирмата одобрени доставчици. Вивек също задава корпоративни функционалните областта на тази покупка (e.g. "IT" или "Финанси").
3. ЕДП базирани поток започва, определя на Paul в пряк ръководител и изпраща заявка към неговия мениджър, Стейси.
4. Стейси одобрява заявка за покупка.
5. ЕДП поток инспектира заявки и определя това е ИТ покупка. Той разпраща работния поток до функционални диспечера на ИТ, Wonson.
6. Wonson одобрява заявки.
7. ЕДП поток отново инспектира заявки и определя че сумата на покупката, надвишава maxium долар и го насочва към разделението мениджър за одобрение.
8. Разделението мениджър одобри заявка за покупка.

Бележки

• Използването случай показва "чиста" тичам без откази или скокове.
• Всеки одобряващ има възможност да одобри или отхвърли заявки, както и да представят писмени коментари. Те са влезли в одит.
• Ако един отговорен мениджър отхвърли искане за покупка във всеки един момент, PO заявки е "мъртъв" и процесът трябва да се стартира от началото.
• Работният поток ще уведоми наредителя на всяка стъпка от процеса на.
• Няма писмени подписи — Клиентът определя (след някои силно въздействащи препоръки) че Одитът пътека както чрез хронологията на работния поток, служи на нуждите им одит.
• Усилие — Отне около три мъж седмици, за да приложи това решение.

Заключение

Този разтвор лостове Мос като развитие и Пусни време платформа. Клиентът е в състояние да се наберат основните Мос функции за автоматизиране на рутинни бизнес процес, който засяга почти всеки служител в компанията. С изключение на прости уеб услуга (която от своя страна лостове Мос), почти никакви действителни "програмиране" е необходима.

Решението също така служи като "витрина" за клиента, демонстрира как различните Мос функции могат да бъдат комбинирани за създаване на напълно функционален бизнес приложение и да генерират нови възможности за консултации в бъдеще.

Речник

МАРС РИКОНИСЪНС ОРБИТЪР: Поддръжка, ремонт и операции. Тези покупки обикновено включват елементи като бележник, столове, персонални компютри, принтери, клетъчни телефони и други подобни.