聽書內容來自商業思維學院2021 聽讀商業書選 《商業流變經營策略》 單元第一篇,內容會參雜部分個人筆記與想法。

如欲瀏覽聽書原始內容可前往連結參考課程:商業思維學院 | 聽讀商業書選

雖然好像很常聽到藍海這個詞,不過好像是這篇聽書聽完才對這個理論比較有一個全貌的了解。

商場上撕扯競爭的區域,是流血的紅海,而藍海指的是商場上尚未被開拓、飽含可能性的一塊新區域。這本書旨在告訴人們為什麼大多數的公司即使知道這一套,也難以航向藍海,如果要航向藍海,那麼漫漫長路該如何前行。

在一開始一些分析後,我解讀到書中提到無法航向藍海的原因,主要還是企業的變革往往會在亡羊補牢之時,多未有足夠餘力能來進行變革,而尚有餘力時,往往又對變革的迫切性難有重視。這很像之前很常聽到的一個概念:「要關注那些重要但不緊急的事」,時刻警惕自己關於自己的視野中不能總只有稀缺或緊急,對大局而言是很重要的。

書中接連舉了兩個例子來介紹所謂的航向藍海,具體會是怎麼樣的一個情形:技術卓越的交響樂團,該怎麼樣在同等卓越甚至技高一籌的競爭者中吸引觀眾?─他們找出了自己的天時地利,利用迥異的主題作為主打,有著能夠引人認同的中心思想,成功的開闢了一條有人支持的路;商業旅館的競爭者眾,什麼才能讓商務人士心儀?─貼近顧客,觀察痛點,尋求洞見,讓他們過濾出目前不同等級的服務中這個客群的需要與不需要,去除不需要,重新組合需要,換來了高達九成的住房率。

書中提出建言,航向藍海的指路燈會是兩者:不要侷限在現有客戶或市場、運用適當的工具或指引方法,發展出新的產品或解決方案(這裡指的要比優化現有服務在高一個層級,會是像整合或組合,是更能發力的槓桿改變)。

這邊有提到一個有趣的詞─價值創新:價值創新有別於技術創新,重於客戶的利益,對以下三者重新定義:客戶需求、市場邊界、產品。這個詞拿去搜尋也會找到大量藍海策略相關的文章,個人認為是藍海策略中的核心詞彙之一。

最後一個段落是本書的重點:藍海策略其實早於這本書數年,這本書更多是在觀察到眾多難以航向藍海的難處後,對工具或方法有了一些建言,下面對人的處理有三,對事的處理有五,這三五技巧,或能協助我們重新思考。

人性化流程:攘外必先安內,對內部成員有三點重要:

  • 切細執行項,透過許多的小成功來建立大家的信心與成就感
  • 讓成員能有機會接觸第一手資訊,減少預設結論的總結式傳達,讓成員能夠透過自己的思考認同改變的必要
  • 平等程序,認可參與者的理智與情感價值,人人有發言與改變的機會,促使心態的開放

起步程序:

  1. 啟動轉型:了解手上產品的在 價值模仿 ─ 價值創新 的軸向上的位置,挑選偏向的遇到困境的價值模仿產品及適合的團隊來做藍海計畫
  2. 了解產業:共同建立策略草圖,共同寫下可能的產業內 5–12個競爭要素,並確保競爭要素的主要述點是由客戶出發,如同外部的人看待產品的角度一樣。
  3. 預想未來:這邊提到的是買方效益圖與三層潛在顧客的思考,這兩個關鍵字而來的工具能幫助我們想像一個更清楚的未來,更能知道我們該找誰來了解進一步的狀況。
  4. 抓出方法:創造/減少/提升/消除四方向來省思自身的產品服務的可能性,也從打開新的價值的角度去思考不同途徑的可能性,根據選定的途徑逐一探詢。
  5. 採取行動:藍海展示會─把上面擬定出來的行動計劃,展示給相關的stakeholder,利害關係人,讓他們能夠給予足夠的意見。接著就是逐步投入市場並觀察反應,視情況調整策略運作範圍或方式。

至此便是大致上航向藍海一書中透過聽書及大綱得到的心得與內容,自己會想起以前的一句話:選擇標準優於選擇選項,在我們挑選執行的策略前,可以更多的思考關於「價值創新」的角度,適當的輔以書中提到的工具與圖像做為細化手段,最後變能有機會能打開一條航向藍海的航道。

最近剛好在研究如何在 Line 的群組做到排程貼文的發布,目的不外乎經營群組想要排程推送內容,自己私人群組用作提醒記事用,便來研究了一下該如何能以最容易且低成本的方式來串起所需功能,謹以此篇文記錄自己的實作過程與該如何套用。

文中會分成實作與套用兩部分,可以直接搜尋關鍵字,看你想看的部分就好:

  • 使用步驟
    > Line Notify 的部分
    > Go …

嘿!菜園裡洋薊已經長的到處都是了!這樣可會把你的菜園弄得一團糟,只剩下一個辦法了:丟棄所有的洋薊!透過收穫新鮮的蔬果來清理你的牌組,這些新鮮的水果能讓你交換,丟棄或堆肥卡牌,想要組成獲勝的一手,你需要一些的幸運、策略,也許綠手指也會很有幫助。

遊戲是個輕快的牌庫構築遊戲,規則簡單易懂,遊戲時長短短的,大概10分鐘內就可以結束一局,適合當穿插小品,一些帶有隨機性的效果也是會在出現意料之外的結果時讓人會心一笑。

遊玩人數 : 2–4人

遊玩時間 : 6–10分鐘

標籤 : #牌庫構築#沒有洋薊即獲勝#丟了那些洋薊

BGA網址:https://boardgamearena.com/gamepanel?game=abandonallartichokes

遊戲一開始會發給玩家10張洋薊構成牌庫,面朝下不用洗牌(因為十張都一樣的XD)直接抽五張,這時候會有五張是手牌,五張是牌庫。

一座獻給索貝克的寺廟正在如火如荼的建造著。相鄰的一座巨大的市場因此崛起,一旁尼羅河沿河的三桅帆船和獨木舟正好能提供相應的資源。你的商人工會和你的對手公會都決定來爭搶這個難得的商業機會,而索貝克神的恩惠,會落在最不浪費的公會來幫他們一把。能在這場競爭中脫穎而出的,就是最後的贏家。

雖然沒玩過索貝克本來的遊戲,但這款兩人版是個輕快的兩人遊戲,透過簡單的價值相乘概念,適時出貨發動獨木舟的驚喜,又或是控制生命之符的方向來限制對手走位,規則容易上手,適合兩人想動動腦的時候來上一局。筆者覺得比較浮動的大概是神的恩惠是捉摸不定的吧,獎勵板塊的分差有時候是很可怕的(苦笑)

遊玩人數 : 2人

遊玩時間 : 20分鐘

標籤 : #移動那個雕像 #成套蒐集 #腐壞乃必要之惡

BGA網址:https://boardgamearena.com/gamepanel?game=sobektwoplayers

Setup的部分麻煩參考說明書直接進行設置,BGA的部分它會幫你Setup好所以這個部份我們就不細說了。

遊戲結束的條件是任一方的回合中無法做任何行動,則遊戲立刻結束。

遊戲最後的目的是比較計分,計分的來源總共有:

  1. 德本(Deban)標記,標記上會有數字,數字等同分數
  2. 出貨: 出貨時的 甲蟲數量 * 上出貨卡片數

至於該透過甚麼管道獲取,我們後面一一敘述

起始每個玩家會有兩張手牌,都會是沒有甲蟲的貨物卡。

我們行不行?一定沒問題!雖然我們這次也是要扮演建築規劃的角色,但並不是規劃建築─我們要來蓋鐵路和公路啦!雖然你可能對建築有一套自己的想法,但天不從人願,你可能沒辦法拿到最好的鐵路,那你是否能夠在這個狀況下,仍然蓋出四通八達的道路規劃呢?這個輕快的遊戲,邀請你一起來築起一片交通網!

看到遊玩人數的時候應該第一個想到的是 Welcome To (笑),實際上看完了規則也是類似的同步進行制的紙筆遊戲,讓我們來開始了解怎麼上手吧。

遊玩人數 : 1–12人

遊玩時間 : 20–30分鐘

標籤 : #紙筆遊戲#紙筆與骰#童年回憶水管工人

BGA網址:https://boardgamearena.com/gamepanel?game=railroadink (房主須為尊榮會員)

基本規則(遊戲時長:7個回合)

遊戲開始時每人會有一片圖板,這是你將要蓋起交通網的地方,我們先統一名詞:

紅色的箭頭⇧:出口

兩條線中間有線的Ξ :公路

虛線┅:鐵路

黑色的方形■:車站

內縮符號〉〈:跨過,表示上下並無交會

規則中如果提到「道路」,表示鐵路或公路都包含在所指對象

遊戲總共會進行7個回合,每個回合會丟出四顆骰子,骰子有兩種:

純道路骰共會有三顆,丟出的圖示可能有以下這些:

村子上的籬笆每天都有好多的小鳥,但是到了該飛回家的時候,他們好像該如何成群結隊有些困難,你能夠幫這些方方正正的鳥兒們組成完完整整的隊伍,好好地飛回家嗎?

這款在BGA的熱門區出現了一陣子了,本來就有簡體中文的官方中文規則,不過昨天實際玩完後來寫一個比較清楚易懂的遊戲規則版本。玩起來是個輕快的成套蒐集遊戲,但是需要的鳥兒遲遲不出現的時候會想說鳥兒是迷路到哪裡去了(笑)。

遊玩人數 : 2–5人

遊玩時間 : 9分鐘

標籤 : #鳥兒在哪裡 #成套蒐集 #左邊右邊都有就夾起來

BGA網址:https://boardgamearena.com/gamepanel?game=cubirds

(簡略帶一下Set Up,這遊戲的設置很快)

遊戲牌組總共有110張牌,起始遊戲時

  • 中間依序發好 3張 * 4列的鳥兒牌,正面朝上,同一種鳥如果在同一列出現多次,棄掉直到同一列沒有同種鳥為止
  • 把所有棄牌跟剩下的牌洗混,每個人發八張手牌,與一張公開的鳥兒牌,代表起始蒐集的1隻鳥兒

好像很久沒寫桌遊規則相關的文章了,昨天玩了一款新的小品桌遊,一樣是在BGA上的,是款開心建築自己城市的遊戲,它的卡牌美術風格都蠻可愛的,圖片或建築也能讓你會心一笑,最重要的是不要只發展人口,也要兼顧城市的幸福度,這樣才能打造一座開心城市喔!

整體上市一款節奏輕快的小品遊戲,沒接觸過策略遊戲的朋友也很適合做簡單的收入購買的營運練習。

遊玩人數 : 2–5人

遊玩時間 : 9分鐘

標籤 : #建築師巴布 #簡易市場 #規則簡單

BGA網址:https://boardgamearena.com/gamepanel?game=happycity

(我預設會來看這篇的人是想快速知道怎麼在BGA玩,一樣會略過Set Up的部分喔,想參考Set Up的請移駕原本說明書,另外拉到底有原本說明書提供的懶人包中翻,幫助你快速了解/回想遊戲大概流程。)

遊戲主要只分兩個階段,收入階段與行動階段:

緣起於今天看到朋友在使用DateTime做Query的時候,發現兩邊同樣TimeRange的Data對不起來,用了DateTime欄位做Group By後才發現是意外撈到了非預期的值,讓我想研究一下官方文件,看看DateTime是不是還有什麼沒注意到的眉角。

讓我們來看看他的撈取區間的寫法:

Select theDataHeSelect
From targetTable
Where DateTimeParameter Between '2021-05-01 00:00:00.000' And '2021-05-07 23:59:59.999'

這樣撈出來的結果,實際上撈出來的數據其實是 ‘2021–05–01 00:00:00.000’ ~ ‘2021–05–08 00:00:00.000’,為什麼明明是寫999,但是系統卻把撈取範圍進位了呢?

這裡是MSDN中有關Sql Server DateTime精度描寫:

可以看到文件清楚寫到,在DateTime millisecond 的尾數位置精度只有三個數字,分別是.000, .003, .007,其他數字都會被逼近到這三個數字,其中最出乎使用者意料的應該又是.999,逼近後會導致時間點的進位,如範例所示,如果用23:59:59.999,進位後會變成00:00:00.000,在進行時間查詢的時候要特別注意,以免寫了個坑坑自己。

另外分享一個之前寫C#串Sql Server踩到的雷,DateTime型別在C#中的Min Date 是 0001/01/01,而Sql Server中的 Min Date是 1753/01/01,如果在串Api輸入的時候,C#中的DateTime沒有賦值的情況下直接傳入,Mapping到Sql Server的DateTime變數,就會拿到這個錯誤。

System.Data.SqlClient.SqlException: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.

那對應的簡單解法有兩個:

  1. 在C#中給予該 DateTime 變數 Default值,且該預設值大於 1753/01/01
  2. Sql Server對應欄位宣告為 DateTime2,DateTime2的支援範圍為 0001/01/01 ~ 9999/12/31,就可以避開這個問題

以上是今天帶來的兩個關於DateTime的雷,與大家分享,希望能讓踩到雷的人雷個清楚,沒踩到的也明白這裡有個坑。

寫Store Procedure的時候,我們常常會需要建立暫時的資料表來協助我們處理資料,一般而言我們會有兩種選項(以SQL Server2000後來說):Temp Table與Table Variable。
而什麼時候要使用哪個,之前筆者其實一直想好好了解一下,這篇文章的內容來自就這個主題下去查詢後得到的內容,若有錯誤請協助指正,本篇內容更偏向個人統整筆記。

我們先來看這個表格,是我歸納各文章中的大多數的內容:

                               Temp Table | Table Variable
tempdb的交易紀錄檔 小 | 大
可否加Index與Default Constraint 可 | 否
Transaction Rollback 可 | 否

這個表是最基本的比較,然而在我看的另一篇文章中有指出不同的看法,上面這些敘述在基本面上是正確的,但是論到根本的實做的話可能又有些不同。

下列再逐一列出一些被提到的論點

  • Temp Table是可以如一般Table一樣使用DDL語句
  • SQL Server會幫Temp Table建立統計數據(Statistics),意味著QO(Query Optimizer)可以選擇適合的計畫,相對來說SQL Server並不會對Table Variable建立統計數據,Recomplie次數會更少
  • 兩者都會寫下交易日誌(Transcation Log),
  • 對大量資料的推薦,一般會建議使用Temp Table,可以吃到Index的好處,另外需要確認Tempdb中的分配空間,避免預設空間過小的問題
    (註:兩者的實例化都是在Tempdb,)
  • 當Store Procedure A 建立了一個Temp Table後,若呼叫Store Procedure B,在B中是可以使用該Temp Table的

其中這篇文章表示(這篇文末也是我上面說有探討根本情況下的一些比較討論,有興趣可以看看),根據作者的測試(內文有它的測試數據),在100,000行以下的行數兩者的效能會差不多,然而隨著資料表的增大,Temp Table的表現會明顯的比Table Variable好。

這個結論跟我看的大多數文章是一致的,當資料集大的時候,會推薦使用Temp Table,小資料集的時候可以依據當下的實作狀況來評估兩者的使用,效能上十分小的話Table Variable甚至會小超一點執行效能,然而隨著資料集的增大,會慢慢的反超,所以在撰寫Store Procedure時應注意操作的資料集對象的量級來評估,若隨著資料源的成長,也要適時評估適合的寫法。

今天在寫Query的時候捏資料,發現自己好像沒好好了解過Decimal的用法跟他的位數定義,以至於遭遇到這個錯誤,今天查了一下來筆記一下TSQL中Decimal的相關知識。

最初遇到的問題的是下面這段SQL

Declare @bookSold table
(
BookCategory NVARCHAR(50),
SellPercentage DECIMAL(5,4)
)
Insert @bookSold(BookCategory, SellPercentage)
Values ('Fantacy',50)

對上面這段按下執行,就會跑出 Arithmetic overflow error converting int to data type numeric. 這個錯誤。

Ok,讓我們先來查看MSDN對Decimal是怎麼說的:

  1. Decimal和Numeric在TSQL中為同義
  2. decimal[ ( p[ , s] ) ]定義時的p為有效位數,s為小數位數
  3. 最高位數值為38(預設為18,舊版中預設為28,關於長度更多可見這裡)

好的,透過解讀以上的內容,我們需要更進一步了解的是有效位數,小數位數個指的是什麼。

有效位數在文件中的解釋是這樣寫的:要儲存的最大小數位數總數。此數目包括小數點的左右兩側。

我們來看下面的對照:

數字 | 有效位數
20.5 | 3
100.73 | 5
67145 | 5

白話一點就是指不管小數點左右邊的位數加總。

而小數位數文件是這樣寫的:小數點右側所能儲存的小數位數。 這個數字會從 p 中減去,以判斷小數點左邊的最大位數。

一樣,來看看範例

數字 | 小數位數
20.5 | 1
100.73 | 2
67145 | 0

小數位數應該挺好懂得,另外,有注意到關鍵字嗎?

沒錯,就是加粗的那段:這個數字會從p中減去。

以我們的例子,我們該怎麼宣告Decimal呢?

數字 | 宣告
20.5 | DECIMAL(3,1)
100.73 | DECIMAL(5,2)
67145 | DECIMAL(5,0)

這樣大家應該知道為什麼我們一開始拿到錯誤了吧。

沒錯,DECIMAL(5,4)的有效位數為5,小數位數為4,所以在這個宣告下能夠塞入的值為 0.0001 ~9.9999,文章首部想塞入50,已經溢位,才會遇到那個錯誤。

AhChao

我的三個關鍵字 : 程式、遊戲、學習 | 3 Key Words About Me : Programing , Gaming, Learning

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