Tại sao giao tiếp trong nhóm lại quan trọng hơn ngăn xếp Martech của bạn

Nhóm Tiếp thị Truyền thông và Phân tích

Quan điểm không điển hình của Simo Ahava về chất lượng dữ liệu và cấu trúc truyền thông đã làm mới toàn bộ phòng chờ tại Đi tới phân tích! hội nghị. OWOX, MarTech hàng đầu trong khu vực CIS, đã chào đón hàng nghìn chuyên gia đến với cuộc họp này để chia sẻ kiến ​​thức và ý tưởng của họ.

Nhóm OWOX BI có muốn bạn suy nghĩ về khái niệm do Simo Ahava đề xuất, khái niệm này chắc chắn có tiềm năng làm cho doanh nghiệp của bạn phát triển. 

Chất lượng của Dữ liệu và Chất lượng của Tổ chức

Chất lượng của dữ liệu phụ thuộc vào người phân tích nó. Thông thường, chúng tôi sẽ đổ lỗi cho tất cả các sai sót trong dữ liệu trên các công cụ, quy trình làm việc và tập dữ liệu. Nhưng liệu điều đó có hợp lý?

Thành thật mà nói, chất lượng của dữ liệu gắn liền trực tiếp với cách chúng ta giao tiếp trong tổ chức của mình. Chất lượng của tổ chức quyết định mọi thứ, bắt đầu với cách tiếp cận khai thác dữ liệu, ước tính và đo lường, tiếp tục với quá trình xử lý và kết thúc bằng chất lượng tổng thể của sản phẩm và việc ra quyết định. 

Các công ty và cấu trúc truyền thông của họ

Hãy tưởng tượng một công ty chuyên về một công cụ. Những người trong công ty này rất giỏi trong việc tìm ra các vấn đề nhất định và giải quyết chúng cho phân khúc B2B. Mọi thứ đều tuyệt vời, và chắc chắn bạn biết một vài công ty như thế này.

Các tác động phụ của hoạt động của các công ty này ẩn chứa trong quá trình dài hạn nâng cao yêu cầu về chất lượng dữ liệu. Đồng thời, chúng ta nên nhớ rằng các công cụ được tạo ra để phân tích dữ liệu chỉ hoạt động với dữ liệu và được tách biệt khỏi các vấn đề kinh doanh - ngay cả khi chúng được tạo ra để giải quyết chúng. 

Đó là lý do tại sao một loại công ty khác đã xuất hiện. Các công ty này chuyên về gỡ lỗi quy trình làm việc. Họ có thể tìm ra hàng loạt vấn đề trong quy trình kinh doanh, đưa chúng lên bảng trắng và nói với các giám đốc điều hành:

Đây, đây, và đó! Hãy áp dụng chiến lược kinh doanh mới này và bạn sẽ ổn thôi!

Nhưng nó có vẻ quá tốt để trở thành sự thật. Hiệu quả của lời khuyên không dựa trên sự hiểu biết về các công cụ là điều đáng nghi ngờ. Và những công ty tư vấn đó có xu hướng không hiểu tại sao những vấn đề như vậy lại xuất hiện, tại sao mỗi ngày mới lại mang đến những phức tạp và sai sót mới, và công cụ nào đã được thiết lập không chính xác.

Vì vậy, tính hữu ích của các công ty này đối với họ là hạn chế. 

Có những công ty có cả chuyên môn kinh doanh và kiến ​​thức về các công cụ. Ở những công ty này, mọi người đều bị ám ảnh bởi việc thuê những người có phẩm chất tuyệt vời, những chuyên gia chắc chắn về kỹ năng và kiến ​​thức của họ. Mát mẻ. Nhưng thông thường, các công ty này không nhắm đến việc giải quyết các vấn đề giao tiếp trong đội, điều mà họ thường coi là không quan trọng. Vì vậy, khi những vấn đề mới xuất hiện, cuộc săn lùng phù thủy bắt đầu - đó là lỗi của ai? Có thể các chuyên gia BI đã nhầm lẫn giữa các quy trình? Không, các lập trình viên đã không đọc mô tả kỹ thuật. Nhưng nhìn chung, vấn đề thực sự là cả nhóm không thể suy nghĩ thấu đáo vấn đề để cùng nhau giải quyết. 

Điều này cho chúng ta thấy rằng ngay cả trong một công ty có nhiều chuyên gia giỏi, mọi thứ sẽ tốn nhiều công sức hơn mức cần thiết nếu tổ chức không trưởng thành đủ. Ý tưởng rằng bạn phải là người trưởng thành và có trách nhiệm, đặc biệt là trong một cuộc khủng hoảng, là điều cuối cùng mọi người nghĩ đến ở hầu hết các công ty.

Ngay cả đứa con hai tuổi của tôi đang đi học mẫu giáo cũng có vẻ trưởng thành hơn một số tổ chức mà tôi đã từng làm việc.

Bạn không thể tạo ra một công ty hiệu quả chỉ bằng cách thuê một số lượng lớn các chuyên gia, vì tất cả họ đều được một nhóm hoặc bộ phận nào đó thu hút. Vì vậy, ban lãnh đạo tiếp tục thuê các chuyên gia, nhưng không có gì thay đổi vì cấu trúc và logic của quy trình làm việc không hề thay đổi.

Nếu bạn không làm bất cứ điều gì để tạo ra các kênh liên lạc bên trong và bên ngoài của các nhóm và bộ phận này, mọi nỗ lực của bạn sẽ trở nên vô nghĩa. Đó là lý do tại sao chiến lược truyền thông và sự trưởng thành là trọng tâm của Ahava.

Luật Conway được áp dụng cho các công ty phân tích

Dữ liệu có ý nghĩa - Định luật Conway

XNUMX năm trước, một lập trình viên vĩ đại tên là Melvin Conway đã đưa ra một đề xuất mà sau này được biết đến với tên gọi phổ biến là định luật Conway: 

Các tổ chức thiết kế hệ thống. . . bị hạn chế để tạo ra các thiết kế là bản sao của cấu trúc truyền thông của các tổ chức này.

Melvin Conway, Định luật Conway

Những suy nghĩ này xuất hiện vào thời điểm mà một chiếc máy tính hoàn toàn phù hợp với một phòng! Chỉ cần tưởng tượng: Ở đây chúng tôi có một nhóm làm việc trên một máy tính và ở đó chúng tôi có một nhóm khác làm việc trên một máy tính khác. Và trong cuộc sống thực, luật Conway có nghĩa là tất cả các lỗi giao tiếp xuất hiện giữa các nhóm đó sẽ được phản ánh trong cấu trúc và chức năng của các chương trình mà họ phát triển. 

Ghi chú của tác giả:

Lý thuyết này đã được thử nghiệm hàng trăm lần trong thế giới phát triển và đã được thảo luận rất nhiều. Định nghĩa chắc chắn nhất về định luật Conway được tạo ra bởi Pieter Hintjens, một trong những lập trình viên có ảnh hưởng nhất vào đầu những năm 2000, người đã nói rằng “nếu bạn ở trong một tổ chức tồi tệ, bạn sẽ tạo ra phần mềm tồi tệ”. (Amdahl to Zipf: Mười định luật vật lý của con người)

Thật dễ dàng để thấy luật này hoạt động như thế nào trong thế giới tiếp thị và phân tích. Trong thế giới này, các công ty đang làm việc với lượng dữ liệu khổng lồ được thu thập từ các nguồn khác nhau. Tất cả chúng ta có thể đồng ý rằng dữ liệu tự nó là công bằng. Nhưng nếu bạn kiểm tra chặt chẽ các tập dữ liệu, bạn sẽ thấy tất cả những điểm không hoàn hảo của các tổ chức đã thu thập dữ liệu đó:

  • Thiếu các giá trị mà các kỹ sư chưa nói qua một vấn đề 
  • Định dạng sai mà không ai chú ý và không ai thảo luận về số chữ số thập phân
  • Giao tiếp chậm trễ trong đó không ai biết định dạng truyền (hàng loạt hoặc luồng) và ai phải nhận dữ liệu

Đó là lý do tại sao các hệ thống trao đổi dữ liệu tiết lộ hoàn toàn sự không hoàn hảo của chúng tôi.

Chất lượng dữ liệu là thành tựu của các chuyên gia công cụ, chuyên gia quy trình làm việc, nhà quản lý và sự giao tiếp giữa tất cả những người này.

Các cấu trúc giao tiếp tốt nhất và tồi tệ nhất cho các nhóm đa ngành

Một nhóm dự án điển hình trong MarTech hoặc công ty phân tích tiếp thị bao gồm các chuyên gia kinh doanh thông minh (BI), nhà khoa học dữ liệu, nhà thiết kế, nhà tiếp thị, nhà phân tích và lập trình viên (trong bất kỳ sự kết hợp nào).

Nhưng điều gì sẽ xảy ra trong một đội không hiểu tầm quan trọng của giao tiếp? Hãy xem nào. Các lập trình viên sẽ viết mã trong một thời gian dài, cố gắng chăm chỉ, trong khi một bộ phận khác của nhóm sẽ chỉ chờ họ vượt qua dùi cui. Cuối cùng, phiên bản beta sẽ được phát hành và mọi người sẽ xì xào về lý do tại sao lại mất nhiều thời gian như vậy. Và khi lỗ hổng đầu tiên xuất hiện, mọi người sẽ bắt đầu tìm kiếm người khác để đổ lỗi nhưng không tìm cách để tránh tình huống đã mắc phải. 

Nếu chúng ta nhìn sâu hơn, chúng ta sẽ thấy rằng các mục tiêu chung không được hiểu đúng (hoặc hoàn toàn). Và trong tình huống như vậy, chúng tôi sẽ nhận được một sản phẩm bị hư hỏng hoặc sai sót. 

Khuyến khích các nhóm đa ngành

Các tính năng tồi tệ nhất của tình huống này:

  • Tham gia không đầy đủ
  • Tham gia không đầy đủ
  • Thiếu sự hợp tác
  • Thiếu sự tin tưởng

Làm thế nào chúng ta có thể sửa chữa nó? Nghĩa đen là làm cho mọi người nói chuyện. 

Khuyến khích các nhóm đa ngành

Hãy tập hợp mọi người lại với nhau, đặt chủ đề thảo luận và lên lịch họp hàng tuần: tiếp thị với BI, lập trình viên với nhà thiết kế và chuyên gia dữ liệu. Sau đó, chúng tôi hy vọng rằng mọi người nói về dự án. Nhưng điều đó vẫn chưa đủ vì các thành viên trong nhóm vẫn chưa nói về toàn bộ dự án và không nói chuyện với cả nhóm. Thật dễ dàng để bạn chìm đắm trong hàng chục cuộc họp, không có lối thoát và không có thời gian để làm việc. Và những tin nhắn đó sau các cuộc họp sẽ giết chết thời gian còn lại và sự hiểu biết về những gì cần làm tiếp theo. 

Đó là lý do tại sao gặp gỡ chỉ là bước đầu tiên. Chúng tôi vẫn gặp một số vấn đề:

  • Giao tiếp kém
  • Thiếu mục tiêu chung
  • Tham gia không đầy đủ

Đôi khi, mọi người cố gắng chuyển những thông tin quan trọng về dự án cho đồng nghiệp của họ. Nhưng thay vì thông báo được thông qua, máy tin đồn làm mọi thứ cho họ. Khi mọi người không biết cách chia sẻ những suy nghĩ và ý tưởng của họ một cách đúng đắn và trong một môi trường thích hợp, thông tin sẽ bị mất trên đường đến người nhận. 

Đây là những triệu chứng của một công ty đang vật lộn với các vấn đề giao tiếp. Và nó bắt đầu chữa khỏi chúng bằng các cuộc họp. Nhưng chúng tôi luôn có một giải pháp khác.

Dẫn dắt mọi người giao tiếp về dự án. 

Giao tiếp đa lĩnh vực theo nhóm

Các tính năng tốt nhất của phương pháp này:

  • Minh bạch
  • Sự tham gia
  • Trao đổi kiến ​​thức và kỹ năng
  • Giáo dục không ngừng

Đây là một cấu trúc cực kỳ phức tạp khó tạo ra. Bạn có thể biết một số khuôn khổ áp dụng cách tiếp cận này: Agile, Lean, Scrum. Không quan trọng bạn đặt tên nó là gì; tất cả chúng đều được xây dựng trên nguyên tắc "làm cho mọi thứ kết hợp với nhau cùng một lúc". Tất cả những lịch, hàng đợi nhiệm vụ, bản trình bày demo và cuộc họp trực tiếp đó đều nhằm mục đích khiến mọi người nói về dự án thường xuyên và cùng nhau.

Đó là lý do tại sao tôi rất thích Agile, bởi vì nó bao gồm tầm quan trọng của giao tiếp như một điều kiện tiên quyết cho sự tồn tại của dự án.

Và nếu bạn nghĩ mình là một nhà phân tích không thích Agile, hãy nhìn nó theo cách khác: Nó giúp bạn hiển thị kết quả công việc - tất cả dữ liệu đã xử lý, những bảng điều khiển tuyệt vời đó, tập dữ liệu của bạn - để mọi người đánh giá cao nỗ lực của bạn. Nhưng để làm được điều đó, bạn phải gặp gỡ đồng nghiệp của mình và nói chuyện với họ tại bàn tròn.

Cái gì tiếp theo? Mọi người đã bắt đầu bàn tán về dự án. Bây giờ chúng tôi có để chứng minh chất lượng của dự án. Để làm được điều này, các công ty thường thuê một nhà tư vấn có trình độ chuyên môn cao nhất. 

Tiêu chí chính của một nhà tư vấn giỏi (tôi có thể nói với bạn vì tôi là một nhà tư vấn) là liên tục giảm bớt sự tham gia của anh ta vào dự án.

Một nhà tư vấn không thể chỉ cung cấp cho công ty những bí mật nghề nghiệp nhỏ bởi vì điều đó sẽ không làm cho công ty trưởng thành và tự duy trì. Nếu công ty của bạn không thể tồn tại mà không có chuyên gia tư vấn của bạn, bạn nên xem xét chất lượng dịch vụ mà bạn nhận được. 

Nhân tiện, một nhà tư vấn không nên báo cáo hoặc trở thành một tay chân bổ sung cho bạn. Bạn có đồng nghiệp bên trong của bạn cho điều đó.

Thuê nhà tiếp thị cho giáo dục, không phải ủy quyền

Mục đích chính của việc thuê chuyên gia tư vấn là giáo dục, sửa đổi cấu trúc và quy trình, đồng thời tạo điều kiện cho giao tiếp. Vai trò của một nhà tư vấn không phải là báo cáo hàng tháng mà là đưa bản thân vào dự án và tham gia hoàn toàn vào công việc hàng ngày của nhóm.

Tốt nhà tư vấn chiến lược tiếp thị lấp đầy những lỗ hổng về kiến ​​thức và hiểu biết của những người tham gia dự án. Nhưng anh ấy hoặc cô ấy có thể không bao giờ làm công việc cho ai đó. Và một ngày nào đó, mọi người sẽ cần phải làm việc tốt mà không cần chuyên gia tư vấn. 

Kết quả của việc giao tiếp hiệu quả là không có hoạt động săn lùng phù thủy và chỉ tay. Trước khi một nhiệm vụ được bắt đầu, mọi người chia sẻ những nghi ngờ và thắc mắc của họ với các thành viên khác trong nhóm. Như vậy, hầu hết các vấn đề đều được giải quyết trước khi công việc bắt đầu. 

Hãy xem tất cả những điều đó ảnh hưởng như thế nào đến phần phức tạp nhất của công việc phân tích tiếp thị: xác định luồng dữ liệu và hợp nhất dữ liệu.

Cấu trúc truyền thông được phản chiếu trong quá trình truyền và xử lý dữ liệu như thế nào?

Giả sử chúng ta có ba nguồn cung cấp cho chúng ta dữ liệu sau: dữ liệu lưu lượng truy cập, dữ liệu sản phẩm thương mại điện tử / dữ liệu mua hàng từ chương trình khách hàng thân thiết và dữ liệu phân tích di động. Chúng tôi sẽ lần lượt trải qua các giai đoạn xử lý dữ liệu, từ truyền trực tuyến tất cả dữ liệu đó lên Google Cloud đến gửi mọi thứ để hiển thị trong Google Data Studio với sự giúp đỡ của Google BigQuery

Dựa trên ví dụ của chúng tôi, mọi người nên hỏi những câu hỏi nào để đảm bảo giao tiếp rõ ràng trong từng giai đoạn xử lý dữ liệu?

  • Giai đoạn thu thập dữ liệu. Nếu chúng ta quên đo điều gì đó quan trọng, chúng ta không thể quay ngược thời gian và ghi nhớ nó. Những điều cần xem xét trước:
    • Nếu chúng ta không biết phải đặt tên cho các tham số và biến quan trọng nhất, làm thế nào chúng ta có thể đối phó với tất cả mớ hỗn độn?
    • Các sự kiện sẽ được gắn cờ như thế nào?
    • Đâu sẽ là mã định danh duy nhất cho các luồng dữ liệu đã chọn?
    • Chúng tôi sẽ chăm sóc bảo mật và quyền riêng tư như thế nào? 
    • Chúng tôi sẽ thu thập dữ liệu như thế nào khi có những hạn chế về thu thập dữ liệu?
  • Hợp nhất dữ liệu chảy vào luồng. Hãy xem xét những điều sau:
    • Các nguyên tắc chính của ETL: Đây là kiểu truyền dữ liệu theo lô hay luồng? 
    • Chúng ta sẽ đánh dấu sự kết hợp của truyền dữ liệu theo luồng và theo lô như thế nào? 
    • Làm thế nào chúng ta sẽ điều chỉnh chúng trong cùng một lược đồ dữ liệu mà không bị mất mát và sai sót?
    • Câu hỏi về thời gian và niên đại: Chúng ta sẽ kiểm tra dấu thời gian như thế nào? 
    • Làm cách nào chúng ta có thể biết liệu việc cải tạo và làm giàu dữ liệu có hoạt động chính xác trong dấu thời gian hay không?
    • Chúng tôi sẽ xác nhận các lần truy cập như thế nào? Điều gì xảy ra với các lần truy cập không hợp lệ?

  • Giai đoạn tổng hợp dữ liệu. Những điều cần cân nhắc:
    • Cài đặt chuyên biệt cho các quy trình ETL: Chúng tôi phải làm gì với dữ liệu không hợp lệ?
      Vá hay xóa? 
    • Chúng ta có thể thu được lợi nhuận từ nó không? 
    • Nó sẽ ảnh hưởng như thế nào đến chất lượng của toàn bộ tập dữ liệu?

Nguyên tắc đầu tiên cho tất cả các giai đoạn này là những sai lầm xếp chồng lên nhau và kế thừa lẫn nhau. Dữ liệu được thu thập với một sai sót ở giai đoạn đầu tiên sẽ khiến đầu bạn hơi bỏng trong tất cả các giai đoạn tiếp theo. Và nguyên tắc thứ hai là bạn nên chọn những điểm đảm bảo chất lượng dữ liệu. Bởi vì ở giai đoạn tổng hợp, tất cả dữ liệu sẽ được trộn với nhau và bạn sẽ không thể ảnh hưởng đến chất lượng của dữ liệu hỗn hợp. Điều này thực sự quan trọng đối với các dự án học máy, nơi chất lượng của dữ liệu sẽ ảnh hưởng đến chất lượng của kết quả học máy. Kết quả tốt là không thể đạt được với dữ liệu chất lượng thấp.

  • Hình ảnh
    Đây là giai đoạn CEO. Bạn có thể đã nghe nói về tình huống khi Giám đốc điều hành nhìn vào các con số trên bảng điều khiển và nói: “Được rồi, năm nay chúng tôi đã có rất nhiều lợi nhuận, thậm chí nhiều hơn trước đây, nhưng tại sao tất cả các thông số tài chính đều nằm trong vùng màu đỏ ? ” Và vào lúc này, đã quá muộn để tìm ra những sai lầm, vì lẽ ra chúng đã mắc phải từ lâu.

Mọi thứ đều dựa trên giao tiếp. Và về các chủ đề của cuộc trò chuyện. Dưới đây là một ví dụ về những gì cần được thảo luận trong khi chuẩn bị phát trực tuyến Yandex:

Tiếp thị BI: Snowplow, Google Analytics, Yandex

Bạn sẽ chỉ tìm thấy câu trả lời cho hầu hết các câu hỏi này cùng với toàn bộ nhóm của mình. Bởi vì khi ai đó đưa ra quyết định dựa trên suy đoán hoặc quan điểm cá nhân mà không thử nghiệm ý tưởng với người khác, sai lầm có thể xuất hiện.

Sự phức tạp ở khắp mọi nơi, ngay cả ở những nơi đơn giản nhất.

Đây là một ví dụ khác: Khi theo dõi điểm số lần hiển thị của thẻ sản phẩm, nhà phân tích nhận thấy một lỗi. Trong dữ liệu lượt truy cập, tất cả số lần hiển thị từ tất cả các biểu ngữ và thẻ sản phẩm đã được gửi ngay sau khi tải trang. Nhưng chúng tôi không thể chắc chắn liệu người dùng có thực sự xem mọi thứ trên trang hay không. Nhà phân tích đến với nhóm để thông báo chi tiết cho họ về điều này.

BI nói rằng chúng ta không thể để tình hình như vậy.

Làm cách nào chúng tôi có thể tính CPM nếu chúng tôi thậm chí không thể chắc chắn liệu sản phẩm có được hiển thị hay không? CTR đủ tiêu chuẩn cho các bức ảnh sau đó là bao nhiêu?

Các nhà tiếp thị trả lời:

Mọi người ơi, chúng tôi có thể tạo một báo cáo hiển thị CTR tốt nhất và xác minh nó dựa trên một biểu ngữ hoặc ảnh quảng cáo tương tự ở những nơi khác.

Và sau đó các nhà phát triển sẽ nói:

Có, chúng tôi có thể giải quyết vấn đề này với sự trợ giúp của tích hợp mới để theo dõi cuộn và kiểm tra khả năng hiển thị của đối tượng.

Cuối cùng, các nhà thiết kế UI / UX nói:

Vâng! Chúng ta có thể chọn nếu cuối cùng chúng ta cần cuộn hoặc phân trang lười biếng hoặc vĩnh cửu!

Dưới đây là các bước mà nhóm nhỏ này đã trải qua:

  1. Đã xác định vấn đề
  2. Trình bày hậu quả kinh doanh của vấn đề
  3. Đo lường tác động của những thay đổi
  4. Các quyết định kỹ thuật được trình bày
  5. Phát hiện ra lợi nhuận không hề nhỏ

Để giải quyết vấn đề này, họ nên kiểm tra việc thu thập dữ liệu từ tất cả các hệ thống. Giải pháp từng phần trong một phần của lược đồ dữ liệu sẽ không giải quyết được vấn đề kinh doanh.

căn chỉnh điều chỉnh thiết kế

Đó là lý do tại sao chúng ta phải làm việc cùng nhau. Dữ liệu phải được thu thập một cách có trách nhiệm mỗi ngày và thật khó để làm được điều đó. Và chất lượng dữ liệu phải đạt được bằng thuê đúng người, mua đúng công cụ và đầu tư tiền bạc, thời gian và công sức vào việc xây dựng cấu trúc truyền thông hiệu quả, những yếu tố quan trọng đối với sự thành công của tổ chức.

Bạn nghĩ gì?

Trang web này sử dụng Akismet để giảm spam. Tìm hiểu cách xử lý dữ liệu nhận xét của bạn.