- CUNYFirstは大学・キャンパスの行政を1つのエンタープライズシステムにまとめるプロジェクトだったが、効率性よりもCUNY Centralの中央統制が優先されたとの批判を受けた
- 適切に実装するには最大10億ドルが必要だったが、CUNYはそれより少ない予算を提示し、Oracle-PeopleSoftだけが残ってカスタマイズなしで設定のみ行うという条件を出した
- CUNYはOracleに約**6億ドル($600m)**を支払ったが、業務はかえって非効率になり、以前は自動化されていた作業に追加人員が必要になった
- 実運用では、古いインターフェース、講座番号の再編、CUNYに合わないセキュリティモデル、複数キャンパスで複数の役割を持つ人を処理しにくいHR構造が問題として明らかになった
- Brooklyn Collegeとその他のWave 3キャンパスは適応できる見込みだが、既存のスケジュール・成績報告用アドオンシステムが消えることで、より大きな不便を被ると予想される
統合行政システムと中央統制をめぐる論争
- CUNYFirstの出発点は、大学とキャンパスの業務プロセスを包括する統合エンタープライズシステムを作ることだった
- 建前としては、重複するサードパーティ製システムの維持コストを減らし、行政・職員・教員・学生によりよい情報アクセスを提供できる構想だった
- しかし、推進の動機は効率性よりも大学活動全般に対する統制に偏っていたという批判が続いた
- カタログ、bulletin、成績証明書と関連の仕組みを統制すれば、カリキュラムも実質的に統制できるという理屈である
- CUNYFirstはPathwaysを押し進める手段の1つと見なされた
- 各大学の裁量資金の存在を把握し、それにアクセスしようとする目的もあったとの批判がある
契約条件が生んだ「設定のみ」の構造
- CUNYFirst導入前の交渉では、適切な実装には最大10億ドルが必要とされていた
- CUNY Centralはそれよりはるかに少ない金額を提示し、入札者のうち1社を除いて残りは撤退した
- 残ったOracle-PeopleSoftは、その予算水準ではカスタマイズせず設定のみ行うと警告した
- この条件のため、OracleがCUNYの既存業務方式に合わせるのではなく、業務プロセスの側がOracleに合わせる構図になった
- その結果、既存機能の一部が失われ、職員・教員・学生は変更後のやり方に適応しなければならなかった
6億ドル支出後の運用負担
- CUNYはこのシステムに約6億ドルをOracleへ支払った
- 実際のコストはOracleへの支払額を上回った
- プロセスがより非効率になったためである
- 以前は自動化されていた業務を処理するため、より多くの人を雇わなければならない状況が生じた
- 負担はHEOsと一部の事務職員に集中した
- 大学運営を実際に支えている人たちが追加業務を背負うことになった
- HEOsは補償なしでさまざまな追加労働をこなさなければならなかった
- 一部の負担は移行過程で生じ、一部はシステム構造そのものに由来していた
実際の利用で明らかになった問題
- CUNYFirstは動作はするが、ひどい動作の仕方をすると評価された
- インターフェースは1990年代初頭の3270 bi-synch技術を更新しただけのようだと批判された
- Web 2.0どころかWeb 1.0にも及ばないという評価が付けられた
- CUNYがカスタマイズ費用を払わなかったため、講座番号を振り直さなければならなかった
- これは教員には見えにくい、多くの強制変更の1つだった
- セキュリティモデルもCUNYの運用方式に合っていなかった
- work-studyの学生が大きな権限を必要とする作業を担うことになった
- その結果、他の学生のデータにアクセスできてしまう状況が生まれた
- HR構造は、複数キャンパスで複数の役割を持つ人を処理しにくい
- 1人があるキャンパスの大学院生でありながら、別のキャンパスの講師であり、第3のキャンパスで非常勤事務職を務めることもあるというCUNYの現実をうまく扱えない
- GMやAppleはそのようには動かないが、CUNYはそのような構造を持っている
Wave 3キャンパスとテストの経験
- Brooklyn Collegeとその他のWave 3キャンパスは、最終的にはCUNYFirstに適応すると見込まれている
- 先行waveの他校でも、すでに適応した例がある
- ただしBrooklyn Collegeは、スケジュール管理と成績報告において学内最高水準のアドオンシステムを持っていたため、より大きな不便を被る可能性がある
- これらのアドオンシステムの多くは廃止される予定である
- 初期テストはベンダーが提供したテストスクリプトに従って進められた
- テストが何度も失敗すると、Oracleのエンジニアが隣の部屋に行って何かを調整し、その後テスターが再試行するという方式だった
- その後、このプロセスはある程度改善されたという話もある
- 個々の利用者にとってCUNYFirstがどれほど不便でも、CUNY Centralの立場から見れば、中央統制という目的を達成する成功したシステムと見なすことができる
1件のコメント
Hacker News のコメント
CUNY の中央本部が、中央集権化・企業型運営のアジェンダを推し進めるために中央 MIS ツールを強く欲しがるあまり、Oracle が設定しかできないという制約の意味を無視した、という見方は興味深い。
私が見聞きした限りでは、特に業務運用の領域では、カスタムプロセスに合わせてソフトウェアをカスタマイズしたり新規に作ったりするより、既製ツールにプロセスを合わせるほうが概してよいと思う。組織は思ったほど特殊ではなく、カスタムプロセスも実際の理由というより初期メンバーの好みに由来していることが多い。カスタマイズは一度きりの費用ではなく、その後のあらゆるアップデートやアップグレードのたびに追加作業、少なくともテストが必要になるし、標準プロセスに近いほど地域の法規制に準拠できる可能性も高くなる。
ただし、自組織に最適ではないプロセスを使うコストは定量化しにくく、カスタムソリューション調達契約のコストは目に見えやすいので、バランスがそのように見えるのかもしれない。
ニーズに合う製品を買えるなら買うが、合わなければ作るし、実際かなり多く作っている。「組織は思ったほど特殊ではない」という言い方にも同意しない。十分に大きい組織なら、他にはない要件が出てくる。今も業界標準ソフトウェアで事業全体を回すプロジェクトを進めているが、結局カスタマイズとカスタム統合を追加しなければならない。この程度に複雑なソフトウェアを社内で作りたいとは思わないが、リソースと課題が与えられれば作れるし、より良い結果になる気がする。
シカゴ方面のコンサルティング会社だったと記憶しているが、最も成功したところは、契約書に「既存の業務プロセスに合わせて SAP を変えるのではなく、業務プロセスを SAP に合わせて変える」といった条項を入れていた。これを受け入れられない顧客は断っていたため、顧客も満足し、従業員の燃え尽きも少なく、際限なく費用が膨らむデスマーチ案件もなかった。
むしろ、人は変えられず、ソフトウェアは変えやすいという前提で複数の事業を作ってきた。
[1] https://www.computerweekly.com/news/252446965/Lidl-dumps-500...
さらに悪いことに、昔の Siebel モジュールと昔の PeopleSoft モジュールの統合が、また別の新しいプロセスを持つ新しい何かに置き換わることもあり得る。いずれにせよ CUNY は、Excel と紙のフォームを持った事務職員を雇うほうが3億ドルは節約できたはずだ。ほとんどは HR 機能を統合しようとする「小文字の p」の political な争いに金を燃やしているように見え、メリットも疑わしい。
Oracleを批判するのが流行っているのは分かるが、この6億ドルという数字は信じがたい。
以前この分野で働いていたが、600万ドルの契約でもかなり大規模で、その100倍となるとますますあり得ない。2013年のCUNY全体の予算は20億ドルにすぎず [0]、これはIT予算ではなく、複数のキャンパス、教員、建物などを含む大学システム全体を運営するための予算だった。高等教育機関は、特に2000年代後半には非常に財布のひもが固い顧客として知られており、大手テック企業も通常の顧客に比べて大幅な割引を適用していた。仮に6億ドルが複数年分、人件費、付帯費用を合算した数字だとしても、そこには近づかないと思うし、その規模の支出ならCUNYの年次財務報告書に必ず表れていたはずだが、関連する記述は見つけられなかった。
[0] https://www.cuny.edu/wp-content/uploads/sites/4/media-assets...
さらに、昨年オンプレミスのPeopleSoft（Oracle）からクラウドへ移行するための1億7,500万ドルの予算要求は見つけた。ただ、私が見てきた限りでは、予算要求額のうち実際にソフトウェアベンダーへ渡るのは10〜20%にすぎず、機関側は全額が承認されない場合に備えて3〜5倍を上乗せしたり、本来なら承認されにくかった職種を採用する機会として、多くの項目をその数字の中に埋め込んだりする。こうした数字も通常、5年分のような複数年予算を前倒しで承認してもらう形だ。言い換えれば、オンプレミスからクラウド版PeopleSoftへ移行する実際の年間コストは、1,000万〜2,000万ドル程度かもしれない。
https://www.cuny.edu/wp-content/uploads/sites/4/page-assets/...
そもそもなぜOracleを選んだのかも疑問だ。大学向けソフトウェアを専門にするベンダーはいくつもあり、その中にはまともなものもあるし大半は微妙だが、大学の要件に合わせるために高度なカスタマイズが必要なOracleソリューションを検討するのは愚かに見える。
大規模で官僚的な多国籍企業でOracleソリューションの実装をしているが、予算の水増しが3〜5倍乗り、5年分の運用費ベースで要求すれば数字がとんでもなく大きくなり得るという話も正しい。数字だけを見る人にはあり得ないように見えるが、実装や契約更新を経験した人は実際の数字を知っている。ただし移行費用は1,000万〜2,000万ドルより高い可能性もある。契約業者の費用も莫大で、時にはソフトウェア費用の数倍になる。
今の仕事で見ていると、ソフトウェアベンダーやサードパーティの実装パートナーが意思決定者と親しい関係を築いていることがある。こうなると、「会社のお金」を使うときのインセンティブが大きく歪む。
大半の学者や大学の管理職が、事業という観点で実際の運営をどれほどできていないかを見ると、今の学界がここまでめちゃくちゃなのも驚きではない
残念ながら、この混乱は価値がきわめて疑わしい学位に対して、破産しても免責されない学生ローンで賄われている。お金の流れを追い、こうしたものの費用を実際に誰がどのように負担しているのかを考えると、本当に苦々しい。この構造全体を学生ローンプログラムが延命している。それを修正するか廃止すれば、米国の学界は崩壊するだろう
退職手続きの中で、リードエンジニアが理想的には開発者をさらに5人採りたいと言っていた。そうするとチームは15人規模になる。開発者8人、DevOps 2人、UX 2人、グラフィックデザイナー1人、PM 1人、エンジニアリングマネージャー1人。このチームが維持しているのは2つだけ。図書館の静的Webサイトと、図書館・博物館コレクション向けのかなり基本的な画像サーバーおよびビューアだ
図書館にWebサイトが必要なのは確かだが、保守には1〜2人で十分だ。画像ビューアはごく少数しか使っていなかった。それでも問題にはならない。学生が授業料を払い続けるのでチームには予算が付き続け、エンジニアたちが一日中YouTubeを見て座っていても世の中は回る
最もひどかった例は、最初の1on1でマネージャーが「[SENIOR ENGINEER X]には多くの成果物を期待しないでください。良いエンジニアではありません」と言ったことだ。組織は誰も解雇しようとしない。結果として、長くいる人たちが責任者になる
ただし解雇も危険ではある。採用があまりに難しいからだ。給与レンジは全職員について大学レベルで決められており、ソフトウェアエンジニアの最高年収が市場価格を大きく下回る。さらに悪いことに、図書館長が対面勤務を義務化しており、大学は人里離れた大学町にある。面接にはコーディングセッションもまったくないが、これが企業風の手続きのせいなのか、単なる無能のせいなのかは分からない
公平に言えば、こうした問題は学界だけのものではなく、大規模組織でも似たものを見た。逆説的に、ビジネスモデルが防弾に近いほど、会社の中で腐敗が育つ余地は大きくなる
行間を読むと、コスト削減とカリキュラムへの制限を求める政治的圧力への対応のようだ
すべてが高くつき、難解なシステム入力が必要だった。費用が天文学的であっても、内部でできるなら内部でやらなければならなかった。外部ベンダーの10万ドルのソフトウェアは、複数のIT部門を通ると確実に20万ドル以上になる。IT部門は少なくとも4つあり、管理者が何層にもいて、全員がとても重要だった
実際、大学システムを運営するのに必要な複雑さや細部、そして大半の大学が抱える不安定な財政の現実を理解しようとする意志が、意図的に欠けていると言いたい。時々、ある学者が自分には壊れているように見えるものを直したり、自分がどれほど賢く正しいかを示したりするために、管理責任を引き受ける。たいてい最初の1年は本人にも周囲にも非常につらく、本当にひどい混乱を生み出す
1年ほど経つと、大学運営、人の管理、リーダーシップについて自分がどれほど知らないかをようやく悟る程度にはなる。その後の反応は3つのどれかだ。管理職を辞任して何事もなかったかのように授業だけに戻るか、謙虚になって実際に協業し、すべてを他人のせいにしなくなるか、さらに意固地になって、解雇されるか担当組織が崩壊するまで全部を壊し続けるか。もちろん全員がそうではなく、リーダーシップへうまく移行する教員は、そもそもかなり謙虚なほうだ
数年前、大学で学校向けの授業管理プラットフォームを作った
それで1,000ドルをもらったのだが、当時大学生だった私には途方もない大金で、学長に会って利用を提案したこともあった。そのとき学校はOracleのソフトウェア購入を検討していたので、私はOracleと競うことになり、当時はこの教授と似たような感情を抱いていた
学校は当然Oracleを選んだ。莫大なお金を使ったはずで、おそらくそれが正しい選択だったのだろう。私はすぐに飽きていた可能性が高い。Oracleにお金を払うのは、良い取引だからでも良い製品だからでもなく、二度とそれについて考えなくて済むようにするためだ
特に結論はない。市場にもっと良い選択肢があればいいと思う。だが、それを自分で作りたいとは思わない。退屈な問題で、顧客もあまり良くないので、教育テクノロジーは売るにはひどい分野だ。Oracleには自分たちにそれだけの価値がある価格帯があり、そのお金を払う顧客もいる
誰かがこの記事を見て学界・政府の無駄に苛立つのではなく、より良い製品で制覇できる大きな市場を見ることを願う。ただ、この記事が2013年に書かれたことを考えると確信は持てない
理論上は気にしなくてよいはずだが、それがかえって無駄を際立たせている。私も何も考えずに500万ドルを使えたらいいのにと思う
だからOracleは、誰も手を出したがらない難しい分野にひどいソフトウェアを売って金持ちになるのだ
それでも、もしかすると世界のどこかには、不要なコストについて実際に時間をかけて考えている人たちがいるのかもしれない
@dang — 現在のリンクの改訂版と思われる、より良いリンクを見つけた: https://psc-cuny.org/clarion/2013/may/cunyfirst-users-last/
この記事はBrooklyn Collegeの教員組合ブログにDavid Arnow教授が書いたもので、Oracleが販売したPeopleSoftベースの履修登録およびHRシステムであるCUNYfirstについての内容だ。このシステムが最近Twitterで注目されたので投稿した: https://x.com/ChocolateyCrepe/status/1836171439965446441
「大学向けHRソフトウェア」のベンダーが5〜6社くらいあってもよさそう
ライセンスを1,000個欲しいなら、1個あたり年5,000ドルで合計500万ドル。実装に1年かかり、25人を送り込んでインストールとユーザー教育を行えば、さらに2,500万ドル。次の1年で他のソフトウェアやシステムとの統合を作れば、また2,500万ドル。ベンダーによって見積もりは±25%くらい変わるはず。新ソフトウェア関連の会議と研修200時間を500人に設定すれば、さらに500万ドル。では、残りの5億4,000万ドルはどこから出てくるのか？
当時、CUNYの学校IT部門で働いていた。本当に笑えるほどめちゃくちゃで、直感的ではなかった
すべての学生にEmployee ID番号が割り当てられ、履修登録は実質的に電子商取引の追加機能として処理されていた
学生証番号が社会保障番号で、氏名と写真と一緒に学生証に印刷されていた。学生証はよく紛失したり盗まれたりしていた
考えてみると、6億ドルもあれば、誰かがこの契約1件を取るために会社を新しく作り、トップレベルの開発者で固めることもできる金額だ
しかし、費用が9桁に達するずっと前から、すでにベンダーロックインが生じていたと思う
他の投稿が指摘しているように、6億ドルという数字が正確かどうかは不明
他の入札者が撤退した件に関連して、総費用見積もりが10億ドルになる主な支出が正確に何だったのか気になる
6億ドルあれば新しいソフトウェアプラットフォームをゼロから作れるので、それ以上の何かがあるはずだ
みんなに嫌われ、組織に実質的な損害を与える高価でゴミのようなシステムは、どうやって売り込むのだろう？ 冗談で「友人が知りたがっていて」と聞いている
大型購入の意思決定がまずく行われるパターンはいくつかある。何をしているのか分かっていない人たちの委員会が、全体として良い判断をまとめられない場合、良い理由で推進しているが何をしているのか分かっていない人、自分の実績として残したいが何をしているのか分かっていない人、「有名な古いベンダーを買って解雇された人はいない」とだけ考え、残りは二の次の人、あるいはベンダーから賄賂を受け取っている人だ。賄賂は、即金、魅力的な営業担当者との事実上のデート、ベンダーとの回転ドア的キャリアといった形を取り得る
賄賂方式は直接見たことはなくニュースで聞いた程度だが、それ以外の悪い方式は確かに全部見たことがある。他にもやり方はあるだろうか？
そして、大きな取り分を持っていく既存のシステムインテグレーターと一緒に仕事をしなければならない