Tak więc AK jest to ktoś, kto rozumie całość ale nie musi (nawet nie powinien) być tym, kto ją implementuje, gdyż tu także ważne jest rozdzielenie roli projektującego od wdrażającego. Role te mają nie raz sprzeczne interesy: im głębiej w szczegółach tkwi dana rola (np. developer) tym bardziej w jej interesie leży utrzymanie status quo, mniejszą ma skłonność do wprowadzania zmian.
Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!
Od jakiegoś czasu śledzę blog WYCIĘTE Z MEJLI (AD ABSURDUM) (gorąco polecam). Dzisiaj przeczytałem to: "Rozumiem, że lubi Pan pracować w photoshopie, ale uważamy że ten program jest za mało…
Dwa lata temu cytowałem: Jakie są najczęstsze problemy w nieudanych projektach? [...] 83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania…
Dobrze opracowany, kompletny model organizacji, łączy w sobie: model motywacji biznesowej, [[model struktury organizacyjnej]], model procesów biznesowych (wymieniony już powyżej), model reguł biznesowych. Elementy każdego z tych modeli są ze sobą powiązane: role w procesach są wywodzone ze stanowisk w modelu organizacyjnym, analizowane procesy są wywodzone z modelu motywacji, reguły biznesowe są kojarzone z czynnościami w procesach i wywodzone z aktów prawnych i wewnętrznych zarządzeń. Mając tak opracowany kompletny model organizacji, zawierający śladowanie, i odpowiednie oprogramowanie CASE można przeprowadzić analizę oddziaływania, np. sprawdzić na jakie osoby w organizacji przeniesie się zmiana wybranych reguł biznesowych. Mając model systemu informatycznego skojarzony z procesami, można sprawdzić wpływ awarii poszczególnych podsystemów na procesy biznesowe i ich skutki dla firmy. Takich analiz można wykonać wiele, nie było by to możliwe bez tak skonstruowanego modelu. Dlatego, podstawową wartością poprawnie wykonanych modeli organizacji i użycia właściwych narzędzi, jest nie tylko opracowanie wymagań np. na oprogramowanie. Możliwe jest testowanie reakcji elementów struktury organizacji na zdarzenia np. awarie. Możliwe jest opracowanie projektów integracji, wymiany oprogramowania. Możliwe jest sprawdzenie na co ma wpływ np. nieoczekiwana obecność pracownika. To tylko wybrane przykłady, jednak możliwe jest to wyłącznie pod warunkiem posiadanie poprawnie wykonanego modelu.