Tak więc proponuję praktykom uważającym, że strategia jest już zbędna, podziękować. Podobnie proponuję podziękować także konsultantom, którzy uważają, że strategia to szczegółowy plan na wiele lat. Nie ma sensu re-definiowanie tych pojęć na chwilowe potrzeby "mody" czy nawet demagogicznego uzasadniania sensu jakiegoś projektu. To i tak na nie zadziała w dalszym horyzoncie działań. Strategia to deklaracja na długi okres, w konsekwencji nie ma sensu by była "szczegółowa", ona ma być ogólna ale musi być "konkretna", musi pozwalać na stwierdzenie w dowolnym momencie, czy to co robimy lub planujemy zrobić (taktyka i podejmowane zadania) jest zgodne z naszą strategią czy nie. W przeciwnym wypadku mamy problem albo ze strategią, albo z planowanymi działaniami, albo z jednym i drugim :) czyli z zarządzaniem w ogóle.
W literaturze można spotkać różne "definicje" studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Wydaje się, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy. Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej, wydaje się być najwłaściwszą.
Poszukiwanie Świętego Graala realizacji celów osobistych albo projektów trwa. Od czasu do czasu pojawiają się "magiczne" metody na sukces. Jedna z regularnie odgrzewanych jest SMART i jej odmiany. Poniżej kolejna próba ożywienia tego tematu i mój komentarz. Model ZOOM mówi o tym, że każdy cel, który sobie wyznaczasz musi być: (Wyznaczaj cele w modelu ZOOM). Moim zdaniem, nie ma znaczenia jaki wymyślimy "fajny" akronim SMART, ZOOM itp...każdy cel w swoim opisie ma trzy kluczowe parametry: to co chcemy osiągnąć, stworzyć itp., to kiedy planujemy to osiągnąć, to jak stwierdzimy, że…
Oprogramowanie workflow, w tak zwanej chmurze, ma wiele zalet, jednak ma także poważną wadę: kłopotliwa integracja z lokalnymi systemami (np. ERP) wynikająca z tego, że dokumenty pokonują zawsze podwójną drogę od naszej lokalizacji do usługodawcy i z powrotem. W przypadku małych firm (mała ilość danych) z reguły nie stanowi to problemu. Dla dużych firm może to być nawet bariera nie do pokonania, dlatego tak zwana "chmura prywatna" czyli lokalna instalacja może być jedynym wyjściem.
Na koniec: zanim zawrzecie Państwo umowę na taką usługę warto się skonsultować z prawnikiem wyspecjalizowanym w tego typu usługach.
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.
Propozycja powyższa (polecam pełny tekst) to próba ograniczenia roszczeń OZZ oraz ograniczenie typów urządzeń objętych tym parapodatkiem. Mam nadzieję, że kropla drąży kamień, i praktyki OZZ o innych "pasożytów" zostaną jeszcze bardziej ograniczone. Dlaczego? Bo miedzy innymi, co jest nie tylko nielogiczne ale jest zwykłym pasożytnictwem, obecne prawo skutkuje tym, że OZZ dostają pieniądze za to, że między innymi moje opracowania (do których nic nie mają owe OZZ), są przeze mnie i moich klientów kopiowane na papier i nośniki CD. Jakim prawem jakakolwiek OZZ pobiera pieniądze za moje dzieła?
Od dłuższego czasu nurtuje mnie czym kierują się ludzie zawierający umowy na zakup pełnych i zintegrowanych pakietów ERP mimo, że statystyki pokazują, że to z reguły nie ma żadnego sensu. Praktycznie wszystkie te wdrożenia są po zakończeniu znacznie droższe niż pierwotne oferty, trwają dłużej niż obiecano, nie mała część kończy się fiaskiem i nawet kompletną rezygnacją i odinstalowaniem (bywam w tych firmach i widzę od środka różnicę pomiędzy tym co piszą w gazetach dostawcy w swoich referencjach a tym co faktycznie miało miejsce).
"przyganiał kocioł garnkowi": w firmach "prywatnych" dokumenty giną znacznie częściej. Mało która firma, nie będące urzędem, ma dobrze zorganizowany system obiegu dokumentów. Owszem, dokumenty księgowe, a konkretnie: dowody księgowe, są z reguły dobrze zarządzane ale to efekt wymagań prawa w tym obszarze. Dobrze jest nie raz także z Umowami, ale tu także mamy wymogi prawne (Umowa jako dokument jest tak samo ważnym dowodem jak np. faktura). Pozostałe dokumenty (oferty, zapytania, pisma do klientów itp.) to w większości firm "towar uboczny".
... zanim ktoś na prawdę zacznie krytykować prawo autorskie, nie zastanowi się zanim zacznie uogólniać. To prawo chroni dzieła Mickiewicza (autorskie prawa osobiste) jak i prace naukowców, architektów, projektantów i wielu innych profesjonalistów. Chroni dorobek żyjących artystów. Owszem, ten rynek żywi wielu pasożytów, ale "atakujmy" pasożytów a nie wylewajmy dziecka z kąpielą, zrównując wielkie dzieła kultury nieżyjących autorów, z tak chętnie kradzionymi utworami muzycznymi współczesnych muzyków popkultury czy dziełami twórców gier komputerowych.
Jednym z największych błędów popełnianych w projektach związanych z modelowaniem procesów biznesowych jest zapominanie o tym, że model procesu to model organizacji a nie tylko dokument, i o tym, że pomiędzy procesami a procedurami, umiejętnościami, instrukcjami obsługi narzędzi, jest granica. To się nazywa utrata panowania nad złożonością projektu. Kolejny problem to powszechne traktowanie notacji (np. BPMN) jako biblioteki symboli, co jest kluczowym błędem: notacja to model pojęciowy - podstawowe narzędzie analizy i modelowania.
Czy się to komuś podoba czy nie, jak na razie, nie ma żadnych "zwinnych umów", są umowy zlecenia (umowa starannego działania) i o dzieło (umowa efektu). Zaś w kwestii zakwalifikowania danej umowy do jednej z powyższych, decyduje jej treść a nie tytuł. Umowa Zlecenia, co ciekawe, nie zawiera pojęcia "licencji" czy "praw", te zawiera umowa o dzieło (tak zwana umowa efektu). Tak więc polecam Państwu krótkie konsultacje z prawnikiem, przed zawarciem "zwinnej umowy", by ocenić jakie ryzyko podejmujecie, bo w umowie zleceniu, wykonawca - pracując i pobierając wynagrodzenie - nie podejmuje żadnego ryzyka, nie licząc, możliwości zerwania trwającej umowy z wykonawcą (co niestety bardzo często ma miejsce w przypadku projektów programistycznych). W takich umowach 100% ryzyka bierze na siebie Klient.
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…
