當出現新技術時，企業領導者是否會嘗試每一項技術創新?企業領導者如何在沒有充分分析和盡職調查的情況下選擇技術供應商?或者由于采購經理、項目管理者或業務利益相關者通過詳盡的研究做出技術決策，以至于企業在采用創新技術之后卻陷入了遺留平臺的困境?
這些決定技術購買的角色存在于許多企業中，這可能會削弱技術領導者做出明智和及時的技術選擇的能力。隨意的技術選擇會導致企業浪費精力并出現技術債務，而過于有條不紊的方法會減緩創新的步伐，并阻礙明智的冒險和敏捷文化。
這些角色可能以各種方式影響企業領導者的技術決策過程，其中包括阻礙企業的技術評估過程到影響何時投資技術以及考慮哪些產品或服務的決策。以下是企業領導者可能做出糟糕技術決策的12種情況。如果企業領導想做出明智的技術決策，不要執行以下操作：
1.接受行政部門的意見作為最終決定
當企業的首席執行官或其他有影響力的高管要求技術團隊購買和實施特定的技術解決方案時，了解其基本原理至關重要。企業領導者試圖解決什么問題?其解決方案滿足預期的程度如何?團隊領導者通常會聽從企業高管的命令，而不是采取措施使方法合理化或提出替代方案。
一種解決方案是制定和呈現愿景陳述的規則，重點關注問題、機會、價值主張。而精心設計的愿景陳述將定義目標，但并未規定采用哪些解決方案或實施方案。即使技術團隊代表企業高管填寫這些內容，也經常會引發對多種解決方案的討論。
2.未能征求或考慮客戶的意見
作為技術人員，有時會犯與企業高管相同的錯誤。他們通常會看到問題，并采用解決方案實施修復。不幸的是，企業領導者在決策過程中并沒有考慮客戶的意見，或者不了解對客戶有什么好處，或者提供不符合要求的功能。
當通過定義角色來開發最終用戶的應用程序時可能會更容易。但是，在考慮后端功能(包括基礎設施、安全功能、中間件、庫或Web服務)時，尋找客戶角色可能更具挑戰性。但技術人員也是業務的一部分。在實施后端技術時，架構師、業務分析師或技術主管可以充當客戶角色的代理，可以提供需求，確定驗收標準，做出權衡決策，并評價他們對實施的解決方案的滿意度。
3.忽略現有的標準和技術
從歷史上看，技術部門一直在努力創建和維護文檔以及溝通和管理標準。因此，當出現緊急請求或最高需求時，他們更有可能尋求新的解決方案，而不是調查和重用現有功能。
這種方法通常會導致冗余能力、半開發的解決方案和激增的技術債務。在研究新解決方案之前或作為其一部分添加“研究內部解決方案”步驟是一個可以增加重用性的簡單原則。當推薦新技術時，創建一個流程來評估對傳統平臺的升級或整合具有類似功能的技術。
4.培育某種供應商和某種方法的技術文化
很多企業通常會強調“我們是一家X店”，以此來減少對其他供應商或技術的任何研究、審查和考慮。擁有首選供應商是一回事，而對第三方一無所知并阻礙采用替代方案是另一回事。
采用強大平臺的少數聲音淹沒在任何探索和實驗中可能會導致代價高昂的錯誤。技術領導者應該解決這種文化反模式，特別是當它妨礙人們提出問題或挑戰現狀的時候。
5.假設構建或購買是唯一的選擇
使用自定義代碼構建解決方案與購買SaaS或其他提供開箱即用功能的技術之間存在很大的灰色地帶。介于兩者之間的是高度可配置的低代碼和無代碼平臺、商業合作伙伴關系以及利用開源技術的機會。
因此，在構建或購買之間選擇是一種簡單化的做法。更好的選擇是所需的功能是否有助于區分業務，以及從長遠來看哪些類型的解決方案可以提供更多的創新和靈活性。
6.假設API滿足集成需求
大多數現代SaaS甚至許多企業系統都提供API和其他集成選項。但是編目集成應該只是調查它們是否滿足業務需求的開始。API公開了哪些數據?是否支持所需的視圖和事務?企業能否輕松連接數據可視化和機器學習工具?API的性能是否足夠，是否存在需要考慮的潛在使用成本?
加速集成功能審查的方法包括這三種驗證API和利用低代碼集成平臺的方法。
7.未能履行社會盡職調查
當人們面臨很多解決方案時，可信賴的信息源可以幫助企業縮小競爭范圍。而閱讀博客、白皮書、評論和研究報告，以及觀看網絡研討會、主題演講和在線教程都是關鍵的學習步驟。但經常被遺漏的一種方法是利用社交網絡向專家咨詢。
8.跳過概念驗證(PoC)
企業選擇技術的藝術和科學涉及設計和執行概念驗證解決方案(PoC)，以驗證假設并測試關鍵戰略要求。在驗證新興技術或評估SaaS平臺時，概念驗證尤其重要，但即使使用敏捷峰值來審查第三方技術組件，也有助于加快制定決策，并避免代價高昂的錯誤。
最大的錯誤可能是跳過概念驗證(PoC)，或者是因為企業只信任供應商，或者面臨時間壓力。而從概念驗證(PoC)中學到的知識可以幫助企業將優先級導向可行的實施方案。
9.沒有制定詳細的決策矩陣
當許多人參與審查和評估新工具和技術時，幫助推動數據驅動決策的一種常見方法是創建決策矩陣電子表格。特性和功能按重要性加權，然后由審查委員會進行評級，并采用電子表格計算總分。
不幸的是，當涉及太多人員、選擇太多功能或分配任意權重時，這些工具很快就會失控。電子表格最終會優先考慮編制者的偏好，而人們通常查看一些無用的東西而忽略了需要戰略性評估的內容。
企業領導者在開始采用決策矩陣之前，考慮將解決方案的特征提煉為業務問題的本質，而不是要求由太多審核者評估眾多的特性。
10.忽略長期架構、生命周期和支持方面的考慮事項
企業領導者需要通過基于易用性和價值實現時間來評估技術，但這并不意味著長期架構、維護和支持不重要或不需要評估。
關鍵是決定何時對它們進行評估、關鍵考慮因素是什么、誰將參與審查，以及在評估中投入多長時間。這樣做的一個很好的方法是將技術團隊在評估開始時應該考慮的控制問題與應作為決策過程輸入的長期因素分開。
11.忽略SLA、數據保護和安全審查
時間壓力或盲目信任選擇的技術是瀏覽服務等級協議(SLA)審查和評估供應商安全和數據保護實踐的糟糕借口。做好這些審查的關鍵需要具備必要的專業知識、談判技巧、工具和有效的評估流程，只有這樣，技術人員和業務贊助商才不會將審查視為瓶頸。
在內部執行服務等級協議(SLA)、數據保護和安全審查的大型企業必須高效，并集中精力將評估與最高風險保持一致。專業知識不足的是小公司應該尋求在解決方案領域具有專業知識的外部人員的幫助。
12.延遲財務和法律審查
最后但同樣重要的是一個是進行財務和法律審查，很多企業并沒有這些領域的專家。
考慮到許多SaaS產品、API服務和云原生技術都有基于消費的定價模型，運營成本可能無法滿足預算或財務限制的要求。法律審查對于受監管行業的企業或在全球范圍運營的企業尤為重要，在這兩種情況下審查合規因素可能特別耗時。對于財務和法律審查的延遲，企業可能會付出高昂的代價。
不要等到技術審查過程結束才引入財務和法律專業知識人才。在此提出的建議是，在一開始就讓他們參與進來，并在企業領導者做出任何技術決策之前權衡需要盡早審查的內容。此外，不要因為一次性進行太多評估，而使財務和法律人員的工作負擔過重。
對許多企業來說，試圖兼顧多項技術評估是不現實的，企業領導者應該優先考慮他們的采購工作。如果這樣做的話，開展智能、全面和高效的技術審查是可能的。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號