次の「興味深い時間」は、私自身の経験を思い出させ、地域の中小ITビジネスの運命を振り返り、ビジネスプロセスモデルの最適化と実装および適切なソフトウェア製品の開発に関与するすべての人々のコミュニティがどのように役立つかを考えさせました。
中小規模のITビジネスが過去25〜30年に渡って歩んできた道は長く困難であり、ビジネスプロセスの質とビジネスの福利厚生には依然として多くの要望が残されています。
構造的な変化が生じた場合、25〜30年前に事業がロールバックしないこと、そしてその進展が続くことを願っています。
この出版物から、このトピックに関する一連の記事を開始し、ソリューションを検索します。
例として次のグループを使用して、情報技術に関連するビジネスの歴史と現在の状態を考慮してください。
1. 90年代後半から00年代半ばに設立され、連邦および国際市場向けの情報システムの開発に携わる若い企業。
電子商取引、電子文書管理、モバイルおよびWebアプリケーション、エネルギーおよび住宅および共同サービス、生産、物流、倉庫、マルチエージェントシステム、さらには宇宙産業など、主題分野はまったく異なります。
企業の一部は外部委託開発に従事しており、もう一方は独自のプロジェクトを持っています。
アウトソーシングは個別の会話ですが、2番目のケースでは、原則として、1つまたは複数の技術プラットフォーム（フレームワーク）が既に開発されており、それに基づいてカスタム開発が行われます。
このアプローチの利点（一見）は、既存の、既に完了したプロジェクトを新規顧客向けにかなり迅速に適応できることです。 ただし、実際には、これにより、各プロジェクトに（顧客ごとに）複数の「ブランチ」が存在するという事実になります。 1つのプロジェクト内のいくつかの「ブランチ」は、互いに同期し、維持し、開発するのが難しく、高価です。 企業は何度かブランチを「マージ」して1つにしようとすると、プロジェクトを再び分割することを余儀なくされます。
そして、結局のところ、それは開発者（プログラマー）の余分な人件費だけでなく、何よりもプロジェクトマネージャー（以下RP）とアナリストです。
RPとアナリストは、初期データを一度収集して要約し、特定の顧客向けにパラメータ設定できる単一ドメインモデルと単一機能を開発するタスクを設定する代わりに、プロジェクトブランチ間に力を吹き込みます。
結果として、時間と労力が不足しているため、アナリストは特定の表記法ではなく、テキストエディターの助けを借りて、画面フォームの反転画像、最も単純なフローチャートとテキストの説明を挿入して作業の結果を作成できます（将来的にはそうではありません）プログラムコードおよびデータベーススキーマと相関しています）。
原則として、このようなプロジェクトのライフサイクルは約3年であり、その後、既存のモデル（分析結果）と開発された技術プラットフォームは、非最適なプロジェクト管理（上記を参照）および非最適なチーム構造の理由により停止しています。
チーム構造のエラーの例：機能の重複、利益相反、必要なリンクの省略（たとえば、データベースアーキテクトの欠如）。
トップマネジメントは、プロジェクトチーム、プロジェクトを監督するトップマネジメント、プロジェクトマネージャー、アナリスト、ソフトウェアアーキテクト、およびデータベースをほぼ置き換えることができます。
その後、新しいタスク設定、分析、技術プラットフォーム、さらにはプログラミング言語など、新しいチームでプロジェクトの作業が新たに始まります。
ただし、多くの場合、プロジェクトの管理とチームの編成では、以前のエラーが残り、その後、ストーリーが高い確率で繰り返されます。
いくつかの推定によると、各プロジェクト内の「ブランチ」間で投げることは、ボックス化されたソリューションの形で各プロジェクトを開発するために必要なコストを超えています。
- 1つのプロジェクト-1つの「ブランチ」。
- 1つのプロジェクト-顧客ごとにパラメータ設定されます。これには、開発チームと開発者自身のアナリスト、アナリストのスタッフがいるディーラーと実装者がチューニングを行う必要がありません。
- いくつかの関連プロジェクト-会社の「ポートフォリオ」内のボックスソリューションは、1つの大きな主題領域をカバーする場合があります。
2. 80年代後半から90年代前半のやや成熟した企業。 情報測定システム、通信システム、テレコミュニケーションの開発、数学的サポートの開発に関与
2.1。 たとえば、元防衛および産業研究機関および設計局は、石油およびガス部門（生産および輸送）向けの情報測定システム（ソフトウェアおよびハードウェアシステムと通信）および関連ソフトウェアの開発に従事していました。 これは、たとえば非常に大規模な防衛通信プロジェクトに従事していた70〜80年代の黄金時代の基準による「小さなトピック」です。
彼らは、顧客と政府機関にとって重要な名前と連絡先、ソビエトの軍事産業の人員と基準に基づいた力の蓄え（時間の経過とともに失われます）、管理リソースへのアクセス、および地域からの連邦レベルでの仕事を持っています。 労働組合の指導者の選挙の波に乗って80年代後半に権力を握った生き残った「レッドディレクター」に何かがかかっています。
腐敗と自発的な意思決定、市場経済における柔軟性のない行動、現代のビジネスおよび生産プロセスの欠如、客観的に必要な組織的および技術的意思決定の不当に長い採用（または一般的に採用しない）がしばしば特徴的です。
2.2。 上記の構造の代表者またはそれらと一度に協力し、同じ問題をより効率的に処理した人々によって設立された小企業。
最初のグループと比較して、タスクは通常、より高度な技術ソリューションを使用して、スケジュールよりも早く解決されます（連邦レベルへの到達を含む、近隣諸国への拡大が見込まれる）
これは、経営者のより現代的な考え方、最初のグループから流れる最高の人材、機動性、単純な組織構造、および意思決定の官僚的な遅れがないために可能です。
予算指向の環境と自然独占の経済状況と行政資源へのアクセスの程度が低い状況では、ある時点で企業が大きな構造の「屋根」の下にユニットがない場合、そのような企業は開発の可能性が低くなります（ただし、このオプションには企業のアイデンティティが失われますおよび関連する利点）。
企業は内部ビジネスプロセスを規定していない可能性があります。最初は、小規模企業はそれらを使用せずに対処し、成長するにつれて「発生したとおりに」動作し続けます。
場合によっては、マネージャーは会社の開発戦略を停止し、状況を「現状のまま」凍結して利益を得ることを試みることができます。これはよく知られた真実と矛盾します。遅かれ早かれ、対応する結果の発生とともに。
2.3。 別に、私たちは、最初のグループの代表者によって設立された中規模ビジネス（長い間大きくなった）に言及することができますが、80年代後半の選出された若い取締役ではなく、取締役-古い任命者の助けを借りて管理リソースを確保します。 そのようなビジネスの創始者はより積極的で成功している-そして、彼らは以前に始め、彼らの以前の仕事から既に知られているトピックではなく、新しいトレンドを取り上げた。
そのようなビジネスの一例は、おそらく有名な地域間通信会社でしょう。
これらのタイプの企業は、小さな町のルーツと適切なビジネス思考、および当初は連邦政府レベルのプレーヤーからの強い圧力のために、開発が困難になる場合があります。
したがって、このような企業は、ビジネスプロセスと組織プロセスを最適化して、コストを削減し、成長の可能性を高める必要もあります。