[生命分享]關係的修復

關係的修復

在現在的社會以及養成教育上，已經出現一個很詭異的現象，就是開始沒有"道歉"的存在，或者說"道歉"只剩下對上的方向，已經失去上對下的"道歉"，所以導致很許多溝通問題的產生與失能，試問多少人有發現這樣的問題已經在不知不覺中漸漸根深蒂固的在我們的潛行為之中，無論是誰都有可能出現一的錯誤的行為，傷害的其他的人事物，甚至是自己卻渾然不知，因為我們已有一種錯誤的觀念，就是自己是對的，因此把關係破壞掉了自己還是渾然不知到。

如何修復關係，行為、認知、觀念等等都需要到位後提出的道歉才會是真正知道此次道歉中蘊含的問題點是甚麼，使其問題開始可以真正的大而化小、小而化無。也可以降低不少溝通上的問題以及使其關係恢復，產生出和睦的關係環境。當紛爭減少了，作業效率也會開始提升，團隊的氣氛也會開始變好，一切的正向循環的啟動，其實都是一種和睦關係的產生，透過這樣的產生不只可以順利地改善環境、關係，更加可以創造出良性循環。

可以回想自己曾經傷害過的人事物，自己有沒有真正的去道歉過，還是都是彼此傷害後彼此不再溝通聯絡，導致於關係的中斷，進而成為彼此之間永遠的傷痕呢！學習改變觀點進而改善自己的生活，更加可以成長。 

[ACL]ACL EXTRACT應用

 ACL EXTRACT 應用

ACL電腦稽核輔助軟體指令雖說不多，但應用上還是需要熟悉，今天先記錄萃取(EXTRACT)的語法。

OPEN 現有資料表名稱

EXTRACT FIELD 欄位名稱 TO 新資料表名稱

OPEN 現有資料表名稱

EXTRACT RECORD TO 新資料表名稱

至今常用的是這兩種萃取方式。

先留下語法未來再加註說明

[工作心得]查核程式與系統程式

查核程式與系統程式

查核程式開發與系統程式開發其實在字面上看上去都是程式語言的寫作，但實質上卻有的明顯的差異，因為撰寫"查核"程式的人是非程式設計專長的查核人員，撰寫"系統"程式的人則會視程式專長的資訊人員，因此在撰寫訓練上其實有很顯著的差異存在，但許多人並沒有從中了解到差異，進而用了相同的管理思維在進行這方面人才的管理與培訓，導致於出現許多人在選擇職業生涯上出現了錯誤的認知。進而常常產生一些認知上的落差與適應不良等問題。

今天我就針對這兩個概念進行一下分析探討：

系統程式：

既然稱之為"系統程式"顧名思義就是各式各樣的資訊系統，所有的一切都有固定的作業流程在觀念在運行，因此每個操作步驟都需要有明確的規範與要求，進而形成的一套資訊系統，這種類型的程式語言寫作上都會能撰寫出對應的規格書以及系統流程圖，而且在這方面的研究已經行之有年，甚至區分出SA、SD、PD等等各個階段的腳色的出現與職權分工，因此相關必要的文件也開始陸續產生對應的撰寫規範與建議，也是職業訓練常見的一環。

查核程式：

這個領域是後期出現的概念，或許因為個人兩方面都經歷過，因此我把查核程式歸類為一種反向驗證的程式寫作模型而非一種程式語言，透過反向驗證的寫作模型去驗證系統程式下的資料是否都有依據企業規範進行作業，從中發現各式各樣的資料缺失，並提出要求改善修正資料，其實概念上就由於工程師在進行資料除錯進行的作業流程，又像逆向工程，只是與資訊界討論的逆向工程不太一樣，這邊的逆向工程是資料面的逆向核對，透過逆向核對找出資料內藏的一些問題。

這兩種其實某種程度上因該是相輔相成的存在，若要統一由資訊開發的概念來看，SD、PD撰寫系統程式是基本能力，而SA則需要有能力去撰寫查核程式，透過這樣的交互關係，進而達到確認系統邏輯與資料推演上是否都符合要求的規範，因此與其說查核程式是一種專門找麻煩的作業流程，不如換個名詞說他是一個驗證用的程式開發模型。

一般而言，系統越大越需要這樣的查核程式協助進行驗證，特別在職場上都會有所謂的客製化程式的產生，強迫將幾個原本獨立的系統串接再一起，進而達到資料控管的要求，但相對地這樣的行為模式也會產生了資料短缺的問題，因此查核程式才因被孕育而生，只是她剛誕生的時候可能只是開發工程師在除錯暫行的一些小程式，因此沒被留意與關注，直到現今的舞弊事件開始不斷產生，才開始有人專門在撰寫這方面的程式，殊不知這早早就在世上誕生了。

結論而言，無論是"系統程式"還是"查核程式"關鍵都是在於知道自己為何而生，自己要做的是甚麼事情，才會走向正確的方向，而不是為撰寫而撰寫，導致於混亂的產生。

[讀書心得]充分授權，完善溝通

充分授權，完善溝通

充分授權在管理上常常見到，但為甚麼往往都不能落實，我個人的見解是一種不安全感的呈現，多少管理者資深人員可以充分授權呢！主要因該都是害怕被取代，因此呈現出一種表面上的說明是會充分授權與信任，但實際執行時去都需要層層回報層層把關，最後再進行作業，導致於實際決策者依然回歸到管理者手上，因此出現不少決策上是有問題的狀況產生，這類情況在部隊生活中最常出現，因此也有過一句話"戰場上的士官指令優於後勤軍官指令"，因為實際在戰場前線的人才能精準判斷狀況，可這句話在實際運行上，往往只是口號，誰敢去冒犯自己的上司呢？

主管的決策若出現問題，往往都會出現下屬給予的資源不足導致錯誤決策，下屬的資源不足又會萌生出主管給予的線索不足等矛盾現象的出現，因此這個平衡該如何去取捨呢，其中就有很深的學問存在，如文件的留存、作業程序上的文化、跨組織支援的窗口等等都會是關鍵，而有些東西本身就不是文件化的東西，可能只是彼此間舉手之勞的協助，可能是一次性作業的任務執行，但這些往往都是到後期進行維護或異常確認時所需要的資源，而這些資源若沒有文件化留存，就會導致資訊存放在管理者的腦海中，此時此刻若出現問題時，就會需要管理者自身出來進行處理才能有全面的資訊與權限。

這樣的矛盾也充分表現出充分授權與有效溝通的重要性，因此在發派任務時，都要去注意是否有充分授權並提供相關所有的資源，以降低資訊不對稱性的狀況，若出現資訊不對稱狀態的現象，往往都會出現所謂的"片面"性的提問，而這樣"片面"問題的提問問題都在提問者嗎？其實都要不盡然是，以資訊工程工作者來說，往往被詢問的問題答案都在系統程式碼之中，然而不再程式碼之中的問題，都只能透過各式各樣的問題形成的拼圖去拼湊而成，而這樣拼圖的呈現往往就是"片面"問題組成，透過組成"拼圖"還原真實狀況，永遠比透過透定人員提供的線索正確。當然看到者裡有人就會說"難道是要彼此懷疑嗎？"，其實並不是要彼此懷疑，如同偵探、警方查案，所有的證詞都是需要有佐證的，而不是一面之詞就可採納，特別今天我們使用的是資訊系統相關的例子，更是如此，畢竟資訊系統最大的特色"系統是照著寫作邏輯走，不是照著人想的邏輯走。"所以我們在任務交代時，不只要提供完整的線索與資源，更要充分授權與溝通才能讓一切走向順利的道路之上。

[工作心得]持續性監控概念

持續性監控的概念

近期接觸到持續性監控/稽核的作業，發現一些觀點需要記錄下來，雖說現今推行的電腦稽核作業很適合進行資料全檢的方式，但是若為持續性稽核的概念進行，"全檢"的概念真的適合嗎？我個人的認知是覺得不太適合，因為檢核重複性會太過於高。而且其實稽核作業都會有一個時間序的概念在裡面，資料範圍若是"全檢"因該只適合於該檢核作業第一次推行，而非持續性進行"全檢"，這一方面是要將資源有效性利用，同時避免重複性作業的消耗，但有許多案件狀況其實在檢核時都會無限往前推進，而這種議題會一直持續發生，倘若只是依據需求撰寫電腦稽核，這樣只是將過去的消耗轉向電腦運作，但最後地確認與報告也是一樣一直報告重複的問題，其實會失去稽核的信度與效度。

電腦稽核是一種事後稽核的概念，因為事情已發生才能顯現出來，而蒐集每次的異常紀錄，從中去回朔了解這些事情發生的緣故，才有可能達到改善作業，因此持續性稽核是一種督促與提醒，而不是一種處罰與不信任，因此在每次稽核報告中都會看到一個欄位"資料區間"，以此來知道每個時段都會有在監控，但就算是持續性也是會持續關注一段時間，而不會永遠的關注下去。倘若持續性稽核的產出每次都出現，可能就會慢慢地不再被有效關注，就像一個人每次量測血壓都偏高，到最後可能會不再去注意血壓偏高的狀況，導致於真的出現高血壓症狀的初期徵兆會直接被無視，因此已經習以為常了。這樣的問題該如何去避免呢？

持續性稽核是督促與提醒，年度性稽核是回顧與改善，概念不太一樣，但執行的項目卻是一樣的，就像企業只有會年度計畫會議，而不會有每月計畫，因為每月只能看到短期執行狀況，卻不能科畫長期的願景與期待，因此在許多問題都是短期改善長期回顧，透過這樣持續性的檢視回顧，猶如個人每周末檢視自己的一週作業狀況，並思考改善作法，並於下周更加成長茁壯，這也算是一種個人改善，也是一種稽核的個人內化的呈現。

總結就是"持續性稽核"是督促與提醒，雖然認被稽核者感到煩躁，其實只是希望可以盡量改善狀況，同時也可以透過這樣持續性產出的資訊，可以找出改善的契機，透過軟體界常常出現的玩笑話"今日的錯誤是明日的需求"，因此今日的缺失產生，會不會就是太提醒管理者其中可能已經有人找到更好的做法，因此需要去關注了解是否有改善的機會已經被醞釀出來了！而不是有缺失必然是錯誤的打壓，導致於措施許許多多的改善契機。共勉之。 

[工作心得]撰寫文件的原則

撰寫文件的原則

所有的管理作業都離不開文件的保留，因此凡事都會需要有文件保留， 都希望透過這樣的文件留存作業保留一直以來的努力產出的心血，可是在撰寫文件時常常會有一些問題的存在，而這些問題似乎一直以來都不被管理者注意到，甚至連撰寫者自己也都沒有發現，而真正發現問題的人都是新接手的人才發現問題，而此時此刻這樣的人可以做到甚麼，因該只有默默承受並設法改善吧！而這樣的做法其實都會有一些負面狀況出現，"前手給我這樣的資訊，為何我要給更完善的資訊給後手"，漸漸地就會呈現出文件是為留存而留存，呈現出交接文件無效化以及制式化的狀況出現。以下以技術文件為例來分享個人觀點。

一、撰寫時先入為主：

在進行文件撰寫時會依據某個特定任務進行撰寫，而此時撰寫時因為撰寫者本身就是開發者，因此會已經取得當時的時空背景與現實資料狀況去撰寫文件，導致出現一些先入為主的名詞出現，而這些名詞有多少人真的看得懂呢？畢竟真的會去看文件的人員，一般都是下一位接手的人在處理事務時去檢視，但這樣的情況就會有認知落差的問題出現。如資料擷取時，若使用的是"部門清單"跟"特定部門清單"這兩個詞看上去都是只有"部門資訊"，但是流程的下一步居然把特定職級人員塞選出來，此時就會讓人疑惑，只有"部門"的資料怎麼有辦法篩選"人員"資料？此例子就可以看出，撰寫者是依據當下取得的資訊進行撰寫，而非注意到當時取得的資訊已經被處理整理過了，導致於直接檢視文件時就會出現許多的疑惑與懷疑，這也呈現出交接文件上的失真以其效力偏低。

二、以檢視文件人員的觀點出發：

在管理文件的撰寫上都會有撰寫規範，而這些規範的定義原始都是為了讓檢視文件的人清楚文件撰寫時各個部分都有固定定義，以方便檢視與思緒轉換，可是撰寫人員因為太過清楚狀況，所以常常會不自覺的省略部分需要說明的資訊，導致檢視文件的人在檢視時都會出現許多疑問跟觀念認知上判定異常，因此產生許多摩擦問題，甚至有些較敏感的人會覺得被侵犯或不被信任感的出現，出現許多溝通隔閡以及組織衝突等狀況。

三、如何讓閱讀者不用再找撰寫者

撰寫文件時，詳細清楚不是撰寫者說的算，而是閱讀者說的算，為甚麼這麼說呢！因為無論是甚麼文件都不是寫來給自己看的，而是寫來讓接手的人看，因此出現常說的交接作業若能順利接下60%就該偷笑了這樣的說法，因為所有的事情都不會比當下進行指導作業，畢竟凡事都有特殊狀況的出現，而越熟悉的人越會自然而然避開特殊狀況，這些特殊狀況會漸漸地被遺忘甚至發生率極低，導致文件撰寫上這些特殊狀況是否該留下感到疑惑，甚至就不自覺得不再留下或輕描淡寫的過去了，這導致於文件留下了，問題也留下了！

最後總結觀念其實就那麼一句話，"好的文件讓人走向未來，壞的文件讓人原地踏步"。

[工作心得]分析作業

 分析作業

在大量數據的時代，透過資料視覺化檢視成果已經是人人都需要具備的能力了，然而現在的市場也具備許許多多資料視覺化的工具，但也產生了一個奇怪的狀況，就是這些工具的推動計畫都是往工具提供了多少圖表，當然為了推工具這是正常的現象，可是卻少了資料分析最重要的關鍵能力，就是數據本身的研究，反而只會想到數據拿到手就是丟到工具內使用產出分析圖，進而導致錯誤的分析報告。

其實想分析數據時需要有一些重點觀念要先培養起來，以下分享希望對各位有其幫助。

一、數據的取得

各種分析動作最基本就是需要取得數據，沒有數據資料先去培養一堆工具技能其實是沒有用的，就像要去安裝一道門，戴上了工具箱，卻沒有去把門板一同帶到現場，這樣就是經驗老道的師傅也是無用武之力吧！所以我們決定要題目時，關鍵點是先取得相關數據，有了數據就像有了門板會知道還需要哪些東西，那些東西值得分析與加工，每個欄位每筆資料特性是甚麼，才能進行下一步。

二、數據的整理

收集到數據後第一件事就是要開始進行整理，畢竟數據取的後需要進行一些整理，因為收集到的數據可能會有短少，需要先把這些缺值找出來才能先將排除依些遺漏，導致於後期分析出來的結果失焦或者不具代表性，因此我們可以避免掉不少失誤，同時也是一種反向驗證資料的正確性與有效性。

三、數據分類/分群

依據不同的議題會有不一樣的資料整理狀況，分類與分群是最常見的狀況，透過分類分群可以開始聚焦問題，並且可以透過各式各樣的分類分群方法來找出我們需要了解的問題與對焦的方向。

四、分析工具的應用

各種分析工具表格類excel、統計類sas、視覺化PowerBI等等各式各樣的工具，而這些其實彼此之間都是相輔相成的，因此不需要說換了工具就認為一切都要從頭來過，這樣的作業方式其實是循序漸進的，原始資料可能在excel之中，再透過sas找出一些統計結果並找出方向，最後透過powerbi視覺化工具回朔追蹤找出發生這類問題時有無徵兆，來進行預測推演得到一個行為模式的結論，進而就可以如大數據分析般，可以找到一些特定行為模式，藉此來預防問題的發生。

最後總結一下，"分析"看似困難，其實難的地方是甚麼，就是不知道目標，若有想探查的目標，這些分析動作與工具，就會成為助力，反之 ，在沒有目標的情況下學習工具，就會呈現出一種為了推廣工具而使用工具的狀況，或許當下被推廣者會覺得好用，往往到實際上線應用就會發現有許多的應用方向其實是混淆自己要探索的焦點，反而造成困擾，因此需要有一個標的物是各種分析作業前需要具備的。