Niestety wiele systemów ERP i i nie tylko, powstało w latach 90'tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i "nad nią" funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie - jak to zachwalają ich dostawcy - zaletą...
SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu: Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at Formal Versions Of SBVR (Źródło: SBVR) A dzisiaj kilka słów na temat aneksu: Annex F - The Business Rules Approach i związku modeli pojęciowych z regułami biznesowymi. Aneks zawiera wyciąg kluczowych punktów Manifestu Reguł Biznesowych (kluczowe punkty): Pierwszoplanowe, a nie wtórne, wymagania 1.1. Reguły są pierwszoplanowymi obywatelami świata wymagań. 1.2. Reguły są kluczowe dla modeli biznesowych oraz technologicznych, stanowiąc jednocześnie ich autonomiczną część. Oddzielone od procesów, a nie…
Wprowadzenie Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy, ostatni jego akapit brzmi: Virtual communication and facilitation skills will remain a key competency for BAs for years to come. Stop torturing your stakeholders with boring, ineffective conference calls. Find new and creative ways to alleviate the common pain points. Please share your virtual facilitation tips in the comments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?). (w uproszczeniu: zdalnie prowadzona analiza to kluczowa przyszła kompetencja analityków, warto przestać torturować ludzi wielogodzinnymi nudnymi spotkaniami, znajdź…
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…
Wymagania to niewyczerpany temat dyskusji, blogów i sporów w projektach. Ich śladowanie już rzadziej jest takim tematem, bo mało kto to robi, a to właśnie między innymi brak śladowania prowadzi do problemów w projekcie. Typowy problem to utrata panowania nad zakresem projektu, utrata panowania nad złożonością dokumentacji i ilości "wymagań" (cudzysłów celowo, później o powodach). W konsekwencji jakość całego projektu upada, zadowolenie sponsorów także (polecam krótki wpis: Why is requirements traceability important on a project?). Dlaczego? Bo skoro wymagania mają być FURPS i SMART, to jak to osiągnąć i jak skontrolować? Jak…
Ta konferencja przekonała mnie, że w sumie to jestem zwinny, bo: moje umowy mają zakres i harmonogram, praca jest iteracyjna, całość bazuje na wizji, opisuję jak stwierdzimy, że wykonałem swoją prace... a specyfikacje wymagań jakie opracowuję, mają nie setki i tysiące pozycji, a góra kilkadziesiąt.
Na koniec największy mit: analiza jest prosta, wystarczy wiedzieć jak ją wykonać i mieć właściwe wzorce dokumentów. Nic tej tezy nie potwierdza, a tak wielu próbuje... Znam masę przypadków, gdy ktoś uznał, że przyuczona grupa pracowników sama wykona analizę wymagań, w końcu to tylko spisywanie potzreb. Niestety nie znam żadnego przypadku gdzie, na bazie tak spisanych wymagań, projekt zakończył się sukcesem. Jest zresztą prosty sposób na ocenę jakości dokumentu opisującego wymagania: skonfrontowanie go z tym co w końcu powstało.
Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :). O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…
Tak więc bezpieczeństwo powinno być raczej elementem wymagań w postaci "oczekiwany efekt" a nie "jak je zapewnić". Nie rozumiem dlaczego tak wielu analityków i działy IT wzbraniają się przed uznaniem, że oprogramowanie powinno być dostępne na dowolnym urządzeniu mobilnym i że nie powinno pozwalać na..., i tu określone ograniczenia. Moim zdaniem bezpieczeństwo powinno być definiowane (wymagania) poprzez ryzyka, których chcemy uniknąć w określonym, biznesowo oczekiwanym (a nawet zastanym) środowisku, a nie poprzez narzucanie konkretnego sposobu i technologii, w szczególności przymusu korzystania z konkretnego sprzętu czy oprogramowania.
Pojawiła się oczekiwana wersja 11 pakietu CASE firmy Visual-Paradigm. Przede wszystkim rozwój produktu idzie w kilku głównych kierunkach: wsparcie dla wizualnego projektowania aplikacji (mock-up'y, kolejne ułatwienia w tworzeniu i integrowaniu modeli UML), stały rozwój wsparcia dla architektury korporacyjnej (to narzędzie pozwala tworzyć modele powiązane ze sobą, pozwala na prowadzenie analiz wpływu i wielu innych, wspiera także notację ArchiMate) oraz na prawdę bardzo silne wsparcie dla pracy grupowej. Co dzisiaj ogłasza producent: Visual Paradigm International Limited today [16.12.2013] announced the release of Agilian (AG) 11.0, a Visual Modeling tool for Agile…
Zadano mi niedawno po raz kolejny dość trudne pytane: Czy Pan to robi lepiej od dużych firm doradczych? Po pierwsze zapytałem "co". I tu pojawił się problem. Z zamiarem napisania tego artykułu nosze się od pewnego czasu, i w końcu rosnąca częstotliwość zadawania tych pytań skłoniła mnie do tego aktu "odwagi". Ja sam zadaję to pytanie spotykanym przedstawicielom dużych firm doradczych a także w kuluarach konferencji, na których nie raz ich spotykam. Zawsze dostaję tę sama odpowiedź: Jarek, Ty i my oferujemy zupełnie inny produkt. Przekopałem się przez oferty "wielkiej…
Nikt tu nie namawia nikogo do pisania zintegrowanych systemów ERPII od zera, jednak dostosowywanie ich (kastomizacja) w zasadzie przeczy zdrowemu rozsądkowi, o czym nie raz już pisałem (wyjaśnienie w cytowanym powyżej artykule). Przypomnę, że mamy tu dwa problemy: pierwszy to koszty kastomizacji dużego systemu są niemalże zawsze większe (ja od 20 lat nie spotkałem się z tym by były niższe) niż zaprojektowane nowego dedykowanego modułu. Drugi: kastomizacja powoduje, że całe know-how firmy (związane z tym dostosowywanym oprogramowaniem) zostaje przejęte przez dostawce oprogramowania, który może handlować nim na rynku.
