31 Followers
·
Follow

Image for post
Image for post

非常有趣,今年我竟然用這麼「怪異」的標題寫回顧。內容方面,也不打算講太多技術、甚至是管理技巧方面,都不想講太多了。當然,會用舉例,以免各種打高空的口號,喊的震天價響,沒半個落地實踐,相信大家在各種平台,facebook, Linkedin等等,心靈雞湯廢文看了也不少。敝人不才,文雖然也不見太實用,至少有憑有據。

於是,就是道青菜豆腐湯。

起因,我正在苦惱如何推動資料改革,才剛跟廠商過完「資料檢驗」,設定落實成為改善的步驟,開始跟催。另外,推動本身公司同仁使用資料、營運做法的習慣。這不就是【data driven】嘛。沒有高大上的機器學習、AI,但掛100%保證賺錢、增進效率。此時,聽到同仁默默地說了一句:「這就像青菜豆腐湯,簡簡單單,但就是這麼簡單,要做的好吃,很難。」

是啊!我竟然被當頭棒喝了。雖然同仁純粹只是脫口而出,我像是禪宗的頓悟一樣,醍醐灌頂來著。工作到了這個高不高,低不低的年紀、職位、技術、工作內容,到底「自我設定價值」在哪?不外求比較,但自省自身,經濟系最愛講的,效益呢?整日幫別人optimize,我自己optimize了嗎?

就被青菜豆腐湯教育了。我沒有用LSTM預測了什麼銷售量生產量,卻紮紮實實的,把整間公司的營運流程,與資料流程、資料管理全串起來了。這其實就是道青菜豆腐湯。青菜、豆腐、水,加些調味料,再簡單不過。要做的好喝、愛喝、是道端的出檯面賣的菜,卻非要些功夫在不可。

請原諒我,近年來,就是有人覺得搞資料的人,脫口就要LSTM、RNN、隨機森林等等這些術語唬人,被迫就是得來這麼一點當作反差例子。

* 我是不想講,搞到最後端出來的全都是k-mean我也是醉了…

Image for post
Image for post

高深莫測,能解決很多難題的,我就比喩做「佛跳牆」吧。確實,佛跳牆料好、費工,做出來精美,端上檯面輕鬆大方。然而佛跳牆要被廣為接受,是相對容易的。青菜豆腐湯,家家戶戶自己會做,要做到別人當作必點的菜色,在檯面上暢銷熱銷,嘿嘿!就不是老王在賣瓜了。

相信很多大廚、名廚,做起佛跳牆簡直不要太簡單,很多客戶也會衝著佛跳牆美名點菜。但佛跳牆成菜好壞,只要工序不出錯,成菜難吃的機會並不至於太高。而且佛跳牆價格高,過於豐盛,很難天天享用,不免曲高和寡。

一碗青菜豆腐湯就不同了,那怕今天是配上一盤炒飯,簡單果腹;或是配上十道大菜,滿漢全席。來上一碗青菜豆腐湯,都不是太突兀。單純的配有均衡的營養、豐富的配也可以清油解膩。

目前的技術、職位、工作內容,就是所謂青菜豆腐湯吧。有滋有味,看起來簡簡單單。卻能保證顧客必點,喝完讚不絕口(公司賺錢)。 此時是不是要國家名廚的頭銜、佛跳牆的配料與豐盛,似乎也無損個人價值的提升了。

簡簡單單,就是碗青菜豆腐湯。

Originally published at http://datamansamxiao.wordpress.com on May 13, 2020.


Image for post
Image for post

首先,開宗明義一下,要做到這樣的事情,是非常辛苦的。除非你願意雞婆管很多事情,然後公司也願意付你相對應的報酬….

這像是把資料報表「模組化」。使用者用他喜歡的模組,自己去兜他要的成品。因為我們知道,使用者的需求總是不斷的變動。當然,早在七八年前,就有類似的商業產品,提供使用者,從「固定」資料內,產生他們要的成品報表。

那當然,這也是幾乎所有資料工程師,最後提供終端資料消費者的成品,是「宇宙無敵超級滿滿的大平台」。換句話說,就是一個可能有著70個columns以上的大table。你要什麼上面都有了。

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

然後身為資料工程基礎人員,我們可能會在各種「組合資料」、「搭建基礎平台」,甚至串好「商業邏輯」中,度過我們的餘生。

表面上,對的,這就是我們的「價值」所在。市場上對我們的期待,對於資料工作者(data scientist, data engineer, data analyst, database administrator, data architect … whatever you want to call this guy…)就是這麼想的。

但,就是那個BUT,小弟不喜歡跟別人一樣。對我來說,光是瞬息萬變的商業邏輯,就是要花非常多時間來維持資料的一致性,以及與真正前端使用者的互動。不僅僅只是自己ETL跑順、報表呈現這麼簡單基礎自動化的事情。

進入正題,你怎麼可能有讓使用者,面對他們business jungle的處境,有不改需求的呢?那解決方式緊接著來,你該如何讓資料的提供平台,更user-friendly,甚至,把夢想做大,user self-sevice!

再次強調,這不是給一個滿滿大平台的這種基本層次。我要user 一起加入ETL的世界。user define、user 參與他自己的報表資料來源!

是的你沒看錯。我為了這個,苦苦的磨了一整年啊!

阿其實也就只要一年啊…. 各位老闆。做不做、有沒有找到對的人做而已。

Image for post
Image for post

小弟於是,將商業邏輯打包,資料底層table切割整理,包成如下圖所示的各模組

Image for post
Image for post

我把模組包成了sales, marketing, finance, customer等類別做為範例。每個模組,代表著裡面所需要的資料,當然我們最重要的,就是把各模組的關聯性、邏輯建立好,然後,將每個關聯性的邏輯,再小心的包成使用者能夠控制的元件。這樣,使用者只要面對他自己定義清楚的元件,該元件背後所代表的資料模組就能產生相對應的作用。

這也不是什麼新鮮事。就是軟體工程的抽象化設計,我拿來用在連接商業世界罷了。

原生架構概念如下,太陽底下沒有新鮮事:

恩概念就講完啦。「說起來」,都超簡單的。接下來要實戰了。不然看了一堆屁話沒有實例,你們不就跟「很多」只會打嘴砲的主管一樣…XD 自己拉椅子吼,不忙。

小弟呈現、實做的工具,是使用 Pentaho server 9.0 (以前大家熟知的Kettle) 當作實踐。當然坊間有各種工具,包含Python, R等。但我必須強調,能夠拿來與user清楚溝通,省去開發工作的話,這樣的平台,你必須不能有太多的code。大家用模組化的元件來溝通,以元件來做需求轉換,才會夠快、夠實際。(其他類似如Trinity, Infomatica等等軟體工具都有,這邊不贅述,我沒拿廣告費)

這邊砸了部分人的飯碗,但我是希望大家往更高層次的地方走,不是只是自己做的很開心,結果沒半點用,進而影響大家的價值

Image for post
Image for post

不要跟我說,你都拿上面這段跟user溝通,我書讀得少,你不要騙我

Image for post
Image for post

不要廢話嘴砲,以下是我的實力 (實例XD)。我都拿這樣的東西跟user溝通,或請user直接自己拉概念。至少user把他要的概念拉起來,我再把概念串成實際的結果!清楚的說明document,資料流,呈現結果!

Image for post
Image for post

再來,user想什麼時候資料更新,就什麼時候資料更新!我的main data flow已經將operation system分層分好。好的資料平台定義,就是user愛怎麼查就怎麼查、愛怎麼組合就怎麼組合!給user放飛的自由,就是給自己自由。這世界上還有很多更有價值的工作等著我們去做!

Schedule你愛什麼時候跑,我就給你什麼時候跑,自己設定,不要來找我麻煩!

Image for post
Image for post

Webpage 操作,你自己連進server跑ETL。我連ETL都給user跑!不然self-service講嘴砲的嗎?然後,你的商業變動行為是能等的嘛?

【喔喔喔是總經理要的喔,那下午就好了】
【這個要等,請你開JIRA工單,我跟PO溝通完後,可能排進下一個sprint做開發】

有沒有熟悉?就是這個味道啊…. 這就是你們要的A……gile……嗎?敏捷式軟體工程嗎?

Image for post
Image for post

好的,又做完了。重點整理一下:

Image for post
Image for post

你的Data Lake、Business process現在走到哪個進程了呢?歡迎批評指教。

Originally published at http://datamansamxiao.wordpress.com on April 29, 2020.


“What’s you action after getting these information?”

Image for post
Image for post

I’m not saying it’s useless. Different roles indicate to different actions. Actually, good job John Hopkins as its role.

But your business is only “reveal of information”? I don’t think so.

本週工作開頭就開始了商業邏輯對策的「行為」討論,讓我又感觸了一下,想發篇文。已經沒做什麼技術更新好幾週了,但這才叫做BI吧!當然,這些行為基礎都是reports與data堆疊起來的。最後的濃縮dashboard,我在現職propose的概念,則是無>有。何謂無>有?也就是dashboard不用畫的美美的了,取而代之的是商業邏輯文字記錄、以及後續需要改善的行為SOP、聯絡窗口,與最重要的資料本身:【一片空白】。【一片空白】,顯示的意義在於「沒事就是好事」。

Dashboard設計的本身是濃縮,也就是一天所有的事情用「一塊」精簡濃縮的圖表就能完全顯示。但結果我們都知道的,哪家公司每天不看幾十個dashboard呢?然後有人看還姑且無所謂,真的有人在看嗎?我是說,每天上班第一件事情就是打開看看dashboard的這種喔!依小弟業內不長不短的經歷,多半沒在看居多,或是看來看去就那一兩個。其它多數都沒在看、或是因為名為”dashboard”,第一線的人都要看細節報告,久而久之誰看summary dashboard?於是,【無>有】的概念就誕生了。

無>有,就是dashboard打開,主資料顯示頁面,最好只有一片空白。另外的部分,放著你需要因應的行為準則,這樣就好。平常上班第一件事情,就是打開,發現統整的資訊,沒有指標需要你動作,然後就關掉。做平常日常工作。一旦出現指標,那就跟著dashboard上的指示,開始做因應的步驟。所以dashboard做出來,非但不會不看,而會是每天先看!因為上面的指示就是最主要的工作與任務,否則請不要放上dashboard庸人自擾擾人。

舉個例子為例,小弟這邊會修改Tableau公開的dashboard當作例子,做為此概念的實踐。例如小弟是蔬果批發商,主要出口的對象是B to C的披薩製造商,跟他們合作拿到的資料整理如下:
(來源: https://public.tableau.com/zh-tw/gallery/popular-pizza-toppings?tab=featured&type=featured )

Image for post
Image for post

以小弟的概念呈現,將會先拿掉原本不在營業範圍內的火腿、雞肉與培根,這並非公司業務所及範圍,呈現對業務沒幫助。再來,定義清楚此張dashboard要解決的業務範圍,我們希望每個蔬果都能夠平均穩定的輸出給客戶,所以我們定義50%當作指標,低於50%就是我們公司可能要有業務銷售的策略,來因應客戶之於終端消費者的需求(end customer)。那我會修改如下:

Image for post
Image for post
  1. 拿掉不必要的資訊
  2. 寫下資料觀測的指標邏輯,每個看到的人那怕只有國小畢業都會看!(不要小看這點)
  3. 寫下需要採取的步驟,有必要就附上詳細資料報告的連結

那何謂真正的好狀態?如下所示:

Image for post
Image for post

什麼都沒顯示,表示銷售狀況一切正常。請跳過做其他日常工作的事情吧!

不贅述了。如概念所示, 無>有

類似概念加映取暖:

https://towardsdatascience.com/dashboards-are-dead-b9f12eeb2ad2

Originally published at http://datamansamxiao.wordpress.com on April 13, 2020.

About

Sam Xiao

用有限的資料知識探索無限的世界

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store